How about having bar in libY.so dlopen() libZ.so, and then obtain frotz() viaQuote:> Consider the following:
> main.c libY.so libZ.so
> built from foo.c built from frotz.c
> and bar.c
> defines quux(), frotz() foo.c defines quux() frotz.c defines frotz()
> and main() and foo()
> main() calls foo() foo() calls bar()
> and quux()
> bar.c defines bar()
> bar() calls quux(),
> and frotz()
> libY.so is built with -B symbolic so that the quux() called from bar()
> is the one in foo.o and not in main. But when main() itself calls
> quux() the one in main.c is called. So far this is what I want.
> But I also want the frotz() called from bar() to be the one i libZ.so.
> Can this be done?
The runtime linker has a very simple mechanism for locating symbols associatedQuote:> I'm using Solaris 2.3 and SPARCcompiler 3.0. I've experimented with
> LD_PRELOAD but it didn't seem to help.
with global relocations: it looks in the application, and then in each of its
dependant shared objects (in the same order as ldd(1) shows). The reason the
-Bsymbolic build of libY.so changes its binding of quux() is because the binding
is actually satisfied and constructed at link-edit time, thus the runtime linker
doesn't even get involved.
The dlopen() namespace gets a little more involved, as it's implemented to
maintain separate relationships between different dlopen() heirachies. See
the Linker and Libraries Manual, Chapter 3, Section ``Adding Additional
Objects'' for a pictorial discription of dlopen() bindings.
I'd be carefull of polluting the namespace with too many multiple symbol
definitions ... it can lead to confusion, and be hard to persuade a de*
what symbol you really want to set a break point on :-)