Hi Ralph, Sorry to be a pain, but again, more questions .. :)
On Sat, 2006-08-05 at 02:30 +0200, Ralf Wildenhues wrote: > I forgot the main part of the answer, sorry. You wrote: > >> The reason I need this capability is to ensure that all the symbols from > >> lib1 and lib2 are available to any dlopen'd modules that get loaded by > >> "myprog". > > The _portable_ way to ensure this is to link each of the modules against > the libraries they need. Period. I assume by module you mean a shared library that will be dlopened and dlsymed by some program. If so, couldn't that lead to runtime link errors? This is actually the problem we're trying to fix! Let me be clear about our situation: Suppose we have a library, foo, that defines exported symbols X and Y. We also have a program bar that uses symbol X but not symbol Y. Finally, we have a "module" (shared object), barmod, which uses both X and Y. If I link both bar and barmod against foo, they will conflict on the definition of X. That is, bar linked in X from foo and barmod linked in X from foo. When barmod is loaded at runtime, we get "duplicate defined" error. This isn't a fictitious case, this is exactly what happens to our modules in some cases (depending on the symbols they use). Our solution is to make bar incorporate both X and Y from foo and then *not* link barmod against foo. At runtime, everything should get resolved. What am I missing? Cheers, Reid. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
