Prev: SIGPIPE doesn't work in Cygwin?
Next: where is good sample code I can learn about linux system programming
From: Ersek, Laszlo on 20 May 2010 19:38
On Thu, 20 May 2010, David Schwartz wrote:

> On May 20, 3:48�am, "carl" <carl@.com> wrote:

>> I don't really see why its necessary to link against somefile.lib since
>> the concrete implementation is already present in the somefile.cpp
>> file.
>
> The somefile.lib file *is* the compiled version of the somefile.cpp
> file. The reason you *do* need to link to the library is because it
> contains the compiled version of the cpp file that contains the
> implementation.

I suppose it wasn't a typo on the OP's part when he wrote "somefile.cpp"
instead of "somefile.o". That is, he may not have seen a separate linking
command at all. For example, in

$ c99 -o program main.c module1.c module2.c

there is no apparent link-edit phase.

I suspect this because the mental jump from explicit .o files to libraries
would have been minimal and intuitive:

Compiling:

$ c99 -c main.c
$ c99 -c module1.c
$ c99 -c module2.c

Linking:

$ c99 -o program main.o module1.o module2.o

Or, if module1.o and module2.o were stashed in a library:

$ c99 -o program main.o -l modules


Cheers,
lacos
From: Gordon Burditt on 21 May 2010 14:28
>> I think what's confusing him is that he doesn't have to specify
>> libraries for many other header files that he uses, like <inet.h>,
>> <math.h>.
>
>Exactly! And what is it in a header file that triggers the compiler to look
>for the corresponding .lib file?

For the compilers I have worked with, *NOTHING WHATSOEVER*. That's
the programmer's problem.

References to functions and definitions of functions are tied together
by the function names (and in C++, the names are mangled based on the
types of arguments and return values).

If the functions you want are included in source files you are linking
together, you don't need to specify a library. If the functions you want
are included in the default C library, you don't need to specify a library.
If the functions you want are in a separate library, you need to specify
linking against that library. zlib, for example, is usually put in its
own library.

A common problem is that the traditional UNIX division of functions
puts a number of functions declared in <math.h> into the math library
(-lm), not the default C library, and it's the programmer's
responsibility to link with the math library if the program uses
those functions. Forget, and you get error messages about undefined
symbols.

Note that it's perfectly possible that you have the .h file for a
library, which includes declarations of functions for that library
and perhaps some structures, but there is no corresponding library
of code *BECAUSE IT HASN'T BEEN WRITTEN YET*. (The header file
contains the design of the interface for the code, which is usually
written first. The actual code may be written later by other project
team members, or even yourself.) Or maybe you just don't have a
copy because it hasn't been released yet. You can test compiling
your code without the library part, but you can't link and run
without it.

You may also be in the position that you have *several* versions
of certain libraries (say, several versions of glibc, or OpenSSL,
or zlib libraries), and it may be up to the programmer to determine
which of the versions, if any, are compatible with the program. It
may be VERY important to include the .h file and link with the
library *FROM THE SAME VERSION* or you get a mess.

>> The reason for this is that there's a library that's normally linked
>> with automatically by default (traditionally called something like "the
>> standard C runtime library", and usually named libc.a). The functions
>> declared in these header files are defined in that library, so it's not
>> necessary to link with it explicitly.
>
>ok that makes sense.
>
>>
>> But zlib is not a part of the standard runtime, so if you want to use
>> its functions you have to say so when compiling.
From: Ryan McCoskrie on 22 May 2010 03:50
Carl wrote:

> I don't really see why its necessary to link against somefile.lib since
> the concrete implementation is already present in the somefile.cpp file.

If every program that used zlib.h had zlib.cpp[1] compiled into it then a
huge amount of hard disk space would be updated and your system would be
much harder to update.

By linking against shared objects all of the programs you have that need
ZLib can refer to one file _while_ _they_ _run_ to get those functions.

[1] Isn't ZLib written in C as opposed to C++?
From: Barry Margolin on 22 May 2010 19:53
In article <ht829r$hm3$1(a)news.albasani.net>,
Ryan McCoskrie <ryan.mccoskrie(a)gmail.com> wrote:

> Carl wrote:
>
> > I don't really see why its necessary to link against somefile.lib since
> > the concrete implementation is already present in the somefile.cpp file.
>
> If every program that used zlib.h had zlib.cpp[1] compiled into it then a
> huge amount of hard disk space would be updated and your system would be
> much harder to update.

That's exactly what *does* happen when you link with zlib.a.

>
> By linking against shared objects all of the programs you have that need
> ZLib can refer to one file _while_ _they_ _run_ to get those functions.

I don't think any of his questions were about shared libraries, they
were about libraries in general.

>
> [1] Isn't ZLib written in C as opposed to C++?

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
First  |  Prev  | 
Pages: 1 2 3 4
Prev: SIGPIPE doesn't work in Cygwin?
Next: where is good sample code I can learn about linux system programming