using libraries with ld (1)

[feldman at ccvaxa.UUCP]

[]
>> Some versions of "ld" support the "-Llibpath" option to specify an
>> additional directory to search for libraries.
>> 
>> You can always just name the library in the "ld" or "cc" command:
>> 	cc -o myprog myprog.o mysub.o mylib.a -lm -lplot
>
> I was under the impression that libraries specified in the way that mylib.a
> is have the entire library linked in rather than just those routines which
> are needed because of undefined identifiers.  Does anyone know if this is
> actually the case?

File arguments to BSD derived versions of ld are examined for a "magic number";
if the file is an a.out file, it is loaded.  If it is a ar archive file things
are more complicated.  In general, the ar file has been ranlib'ed since it
was last ar'ed.  In this case, only what is needed gets loaded.  Otherwise,
ld complains about the library being out of date or not having been ranlib'ed
and makes a single pass through the library, which often leaves undefineds.

Ld pays no attention to filename suffixes, so for example, -lg (/usr/lib/libg.a)
is really a .o file and gets loaded no matter what.  Explicitly named libraries
are treated the same as -l arguments except in the way they are located (/lib,
/usr/lib, /usr/local/lib, -Lpath(?)).  If a -l option turns out to be an a.out
file, ld uses the argument, not the expanded pathname, as the filename symbol.
For example, -lg results in the a local symbol "-lg" appearing in the output
symbol table.

Ld will also use the size of a common symbol (undefined external with non-zero
value) from a library member WITHOUT loading library member if that member
resolves no other undefined references.  This can cause the resulting a.out
file to be unexpectedly big.  I'm waiting to see if this is fixed in 4.3.

Mike Feldman
Gould Computer Systems
Urbana, IL
{ihnp4|pur-ee}!uiucdcs!ccvaxa!feldman
/* End of text from ccvaxa:net.unix */