Q: shared libraries, modified search order

Q: shared libraries, modified search order

Post by Rod Eva » Wed, 01 Feb 1995 08:27:52




Quote:> 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?

How about having bar in libY.so dlopen() libZ.so, and then obtain frotz() via
dlsym()?

Quote:> I'm using Solaris 2.3 and SPARCcompiler 3.0.  I've experimented with
> LD_PRELOAD but it didn't seem to help.

The runtime linker has a very simple mechanism for locating symbols associated
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 :-)

Rod.

 
 
 

1. Search order for shared libraries (ld-linux.so and ldconfig)

Hello,

Two questions about the search order for shared libraries, one to do
with run-time name resolution, and one to do with ldconfig.

QUESTION 1

According to ld.so(8) man page the dynamic linker searches for shared
libraries in the following order

1. Dirs listed in LD_LIBRARY_PATH

2. Libraries listed in /etc/ld.so.cache

3. /usr/lib AND THEN /lib

My tests (SuSE 6.4, kernel 2.2.14, glibc 2.1.3) indicate that the last
of these is wrong - that is, /lib is searched before /usr/lib.  (Using
the dlopen() API, unsurprisingly, gives the same results)

Am I seeing a configuration issue or a documentation bug?  A couple of
things make me think the latter.  One is that the linker (ld) seaches
for libraries in the order /lib and then /usr/lib.  The other is that
the order seems more 'intuitive' - /lib contains the essential libraries
for startup, and thus seems a more natural place to start the search.

I have had a long trawl through glibc (elf sub-dir) sources and cannot
find the code specifically defining the search order.  If anyone happens
to know the piece of code, I'd be interested to know where it is.

QUESTION 2 (Closely related to the previous)

The ldconfig man page isn't precise, but states that in building the
cache (/etc/ld.so.cache) that it searches for libraries :

"in the directories specified on the command line, in the file
/etc/ld.so.conf, and in the trusted directories /usr/lib and /lib"

There is an implied order in this statement, but my testing indicates
the order is this

1. Dirs on cmd line
2. /lib
3. /usr/lib
4. Dirs listed in /etc/ld.so.conf

Can anyone confirm this (and again pointers to the appropriate point in
the source would be handy if anyone has them) or tell me whether it is a
configuration issue?

Thanks

Michael
-----------------------------------------

Michael Kerrisk,
michael.kerrisk (AT) gmx.net

2. Free Dir of Manufacturing Execs

3. modifying a binary's runtime library search path

4. X-server for Intel 810 'Whitney' chipset (or i752)

5. Search order for ELF libraries

6. virtex Segmentation Fault?

7. order of init shared libraries

8. XFree86 failed

9. Modifying shared library on solaris 2.5

10. Order in which shared libraries are loaded at runtime

11. Shared library initialization order.

12. Initialization/Load order of shared libraries

13. Will strip(debug shared library) == nodebug shared library ?