From: Jens Thoms Toerring on
carl <carl@.com> wrote:
> In a program I include the file zlib.h. When I include that file I suddenly
> needs to specify a library file which it should "link against". Why does
> some .h files need a library file and what does it mean that it links
> against the library file?

I guess zlib.h isn't a header file you wrote but that comes with
some packages (probably the zlib package). Then this package
will include typically (at least) two things, a library and a
header file.

The library contains the (already compiled) code for all the
functionality of this package. None of this is in the header
file. What the header file contains is mostly "declarations"
of the functions in the library, i.e. their names, their
return vaue types and the kind of arguments they take.

What are these "declarations" good for? They are mostly meant
for the compiler. If there's a function you want to use in
your program and it's declaration in the header file is e.g.

int * inflate( int a, const char * y );

then this will tell the compiler that this function returns
an int pointer and takes two arguments, an int and a char
array. Now if you call the function with wrong arguments
in your program then the compiler can warn you that you do
something potentially dangerous. And if you assign the return
value to something else then an int (or void) pointer it also
will warn you. It's also important for the compiler to know at
least the return value of the function in order to be able to
pass it back to your program correctly (in C, if the compiler
doesn't know the return value type of a function, it will
blindly assume that it's a simple int - but if this isn't the
case you could end up with very strange run-time errors).

The necessity to link against the library does not result from
including the header file - you can include header files all
day long without needing to link explicitely against a single
library. The necessity to link against the library comes from
using a function from the library in your program. These func-
tions aren't, as pointed out above, in the header files (there
you find only information what they return and what arguments
they take), but the code for the functions is only in the li-
brary. And without linking against the library the linker has
no idea where to take them from, so it will throw a fit and not
create your program.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de
From: Barry Margolin on
In article <ht1kuk$n8n$1(a)reader1.panix.com>,
John Gordon <gordon(a)panix.com> wrote:

> In <4bf447b7$0$281$14726298(a)news.sunsite.dk> "carl" <carl@.com> writes:
>
> > In a program I include the file zlib.h. When I include that file I suddenly
>
> "Suddenly" implies that this was not happening before you included the .h
> file. Is this correct? After adding the statement #include <zlib.h>,
> your program suddenly stops compiling?
>
> > needs to specify a library file which it should "link against". Why does
>
> What is telling you that you "need to specify a library file"? Is it
> your compiler? Please post the exact error message that you're seeing.
>
> > some .h files need a library file and what does it mean that it links
> > against the library file?
>
> It means that while the .h file contains stuff like function prototypes,
> the actual *code* for those functions is in the library.
>
> Think of it like a manual for a washing machine. The manual tells you
> how to use the machine, what to expect during operation, how to fill it
> with soap, etc. But if you want to actually wash clothes, the manual
> alone isn't enough. You still need the machine itself to do the work.

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>.

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.

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.

--
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 ***
From: David Schwartz on
On May 19, 2:18 pm, "carl" <carl@.com> wrote:

> But what is the difference between including a file and linking against a
> file?

Including a header file, again on most platforms you are likely to
use, makes the compiler act as if everything in the header file were
part of the file you are compiling. Linking against a file causes
references in your program to be attached to functions in the file you
link against.

So, for example, if a header file contains a line like:
extern int Foo(int j, long p);
That tells the compiler that if you call a function called 'Foo', it
takes an int and a long and returns an int. So if the compiler sees a
line like:
Foo(3, 4);
It knows that '4' needs to be passed as a long.

However, it still has no idea where the actual function called 'Foo'
is. So this code will compile correctly, but the linker will have no
idea what to do with the call. That's where passing a library to the
linker comes in. It actually allows the call to 'Foo' to be attached
to the function.

In sum:

Header files allow the compiler to generate the correct code to invoke
functions, pass the parameters correctly, and accept the return values
correctly. They also may contain things like structure definitions
that allow code that accesses structures to extract the definitions
correctly. In principle, a header file can contain anything a code
file can, since the compiler acts as if the header file was part of
the code.

Libraries allow the linker, assuming the compiler has generated the
correct calling code, to hook up calls to the correct functions. The
libraries can either actually contain the code that is called in
binary form or they can contain code that loads the libraries at run
time and finds the actual code.

DS
From: Rainer Weikusat on
"carl" <carl@.com> writes:
> "David Schwartz" <davids(a)webmaster.com> wrote in message
> news:7a831dd7-d544-427f-801b-2396a1361cad(a)j36g2000prj.googlegroups.com...
> On May 19, 1:18 pm, "carl" <carl@.com> wrote:
>> In a program I include the file zlib.h. When I include that file I
>> suddenly
>> needs to specify a library file which it should "link against". Why does
>> some .h files need a library file and what does it mean that it links
>> against the library file?
>
> In most platforms you are likely to use, when you include zlib.h, it
> literally includes everything in the zlib.h as if you had typed it
> into your program. So anything you could do in the program can be done
> in the header file.
>
> DS
>
> But what is the difference between including a file and linking
> against a file?

'Including' is done by the preprocessor and the result is fed into the
compiler (and the assembler) to produce an object code file. A set of
(suitable) object code files can then be combined to create an
executable program and this combination step is called 'linking' (and
performed by the linker or link-editor).
From: Scott Lurndal on
"carl" <carl@.com> writes:
>In a program I include the file zlib.h. When I include that file I suddenly
>needs to specify a library file which it should "link against". Why does
>some .h files need a library file and what does it mean that it links
>against the library file?
>

It is the difference between "interface" and "implementation". The
header file (zlib.h) describes the interface, while libz.{a|so} provides
the implementation.

scott