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. _______________________________________________ Help-gplusplus mailing list Help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
