Re: shared versus archive library

[Greg]

Thanks for a reply.
I don't have a small example that I could post here.  The one example
that I did try behaved in an opposite way of what my problem is.  But
let me explain in a clearer way what the situation is.

I have a library that multiple executables link with.  Some of the
functions in the library invoke functions that the executables are
supposed to provide. These are analogous to callbacks.  Some
executables provide definitions of these callback functions and some do
not.  The ones that don't, don't invoke the functions calling callbacks
so the linker shouldn't care about the fact that the callbacks are not
provided.  All object files (within the library and within executables)
are compiled with -ggdb and -fPIC.  No other compiler flags (save for
-I and -D) are used.  The library objects are collected into a static
archive (.a) and shared library (.so).  The .so lib is compiled with
-ggdb -fPIC -shared.

Here is what I don't understand:
When I link the executable with the static lib, .a, Everything links
fine and the code runs.  But if I link the executable with the shared
library, .so, the linker complains about unresolved symbols.  The
symbols correspond to the missing callbacks that the executable doesn't
really need.  If I force the linker to complete with the
--allow-shlib-undefined flag, then the program links.  But when I try
to run it, I get a message from the loader saying that these symbols
(or at least the first one) are undefined.  So it appears that when the
shared library is built, the compiler doesn't optimize out the
callbacks.

Is there a way for me to instruct the linker to ignore the missing
callbacks that it gets from the .so library?  Somehow I need to be able
to do that the loader doesn't attempt to resolve these symbols.

Hopefully this is clearer to understand.  Thanks.