Re: shared versus archive library

[Paul Pluzhnikov]

"Greg" <greg.szeszko@tradingtechnologies.com> writes:

> This doesn't link with the following error:
> libtst.a(a.o)(.text+0x190): In function `aempty()':
> : undefined reference to `anonexistant()'
>
> That is a surprise since aempty is not called at all.

As explained in linker.html I referenced before, the librarian takes
the *whole* book off the shelf, if she needs *any* symbols from it [1].

> I suppose that
> since a function from a.o was needed, all of its functions were pulled
> in and thus required resolution.  If that is the case, then it is
> something new to me as I always thought that functions were resolved
> and used one at a time.

Functions in *shared* libraries are resolved "on demand" or one at
a time at *runtime* -- this is called lazy resolution. But this
has nothing to do with what happens at link time.

> This example seems to imply that once a file
> is opened and one function from it is used, all of the functions have
> to be resolved.

Correct, but see [2].

> Going back to your explaination...  The object files that contain
> functions referring to the missing callbacks are pretty big.  It is
> hard for me to imagine that all of the functions in a give object file
> are left out of linking.

You can *verify* that this is the case. Let's assume that the big.o
defines foo(), bar() and baz(). Simply run 'nm a.out | egrep "foo|bar|baz"'

If you get empty output, that confirms that no part of big.o was
pulled into a.out.

> My actual code files would be closest to your example 2.

It can't be: when example 2 is linked with --allow-shlib-undefined,
it turns into example 3 and *runs*.

Since your executable doesn't run, it must be different from examples
2 and 3 in some way. In *what* way is it different?

BTW, my examples were tested on Linux FC2; and you are yet to reveal
what platform you are on. 

> Is there any
> way to resolve that situation so that the program links with a .so and
> runs?

Most likely there is. But I can't tell you since you haven't yet
explained how your code is different. [I assume you've checked that
LD_BIND_NOW is *not* set for your executable.]

Cheers,

[1] AIX linker is a notable exception -- it retains referenced
parts of objects (called CSections) and discards unused parts;
effectively operating as if each function and each global datum
resided in its own object.

[2] On ELF platforms with recent 'gcc' and 'binutils', *in theory*
one can use -ffunction-sections and -fdata-sections to effectively
achieve the same result as [1] above. From "info gcc":

`-ffunction-sections'
`-fdata-sections'

     Place each function or data item into its own section in the output
     file if the target supports arbitrary sections.  The name of the
     function or the name of the data item determines the section's name
     in the output file.

     Use these options on systems where the linker can perform
     optimizations to improve locality of reference in the instruction
     space.  Most systems using the ELF object format and SPARC
     processors running Solaris 2 have linkers with such optimizations.
     AIX may have these optimizations in the future.


If you try to use these options, be sure to link with -Wl,-O,--gc-sections.

This worked for Konrad Eisele, but didn't work for me on Linux,
as documented here:
http://groups.google.com/group/gnu.gcc.help/browse_frm/thread/7c3ab81d05180fb4

-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.