How are shared library dependency paths determined on Linux?

Question

When I run ldd against a shared library such as libphp5.so I see that it has a dependency on libmysqlclient.so.16:

$ ldd ./libphp5.so
libmysqlclient.so.16 => /usr/lib/mysql/libmysqlclient.so.16 
[other dependencies snipped out]

Are these dependency filenames and paths (/usr/lib/mysql/libmysqlclient.so.16) baked into the shared library binary? Or is this path determined by some other means such as via /etc/ld.so.conf.d/mysql-i386.conf, which incidentally contains:

/usr/lib/mysql/

One other thing is puzzling me:

There is a shared library I have that I compile from source. This has a dependency on libmysqlclient_r. The gcc compiler switches to produce this this library look like:

gcc -shared -L/usr/lib/mysql -lmysqlclient_r [+various other switches]

When I do ldd mylib.so I see:

libmysqlclient_r.so.16 => /usr/lib/mysql/libmysqlclient_r.so.16 (0x0055c000)

However in the /usr/lib/mysql directory I see:

-rwxr-xr-x. libmysqlclient_r.so -> libmysqlclient_r.so.16.0.0
lrwxrwxrwx. libmysqlclient_r.so.16 -> libmysqlclient_r.so.16.0.0
-rwxr-xr-x. libmysqlclient_r.so.16.0.0
lrwxrwxrwx. libmysqlclient.so -> libmysqlclient.so.16.0.0
lrwxrwxrwx. libmysqlclient.so.16 -> libmysqlclient.so.16.0.0
-rwxr-xr-x. libmysqlclient.so.16.0.0

libmysqlclient_r.so is a symbolic link to libmysqlclient_r.so.16.0.0, so why does ldd show the dependency as libmysqlclient_r.so.16. Is there some magic I'm missing here?

_{Having been a Windows dev for many years I'm a bit new to gcc and development on Linux.}

My Linux distribution is CentOS 6.0 x86-32bit.

Employed Russian · Accepted Answer · 2011-11-17T17:53:46.947

15

You can see which paths are coming from where by running

LD_DEBUG=libs ldd ./libphp5.so

Are these dependency filenames and paths (/usr/lib/mysql/libmysqlclient.so.16) baked into the shared library binary?

The filename almost certainly is. The path usually isn't. You can see what is baked into the binary with

readelf -d ./libphp5.so

Look for (NEEDED) and (RPATH) entries.

Also give man ld.so a read. There are many factors that affect how dynamic loader searches for shared libraries: ld.so.conf, LD_LIBRARY_PATH, whether the executable is suid or not, how glibc was configured, which -rpath settings were given at link time, etc. etc.

edited Nov 17 '11 at 17:53

answered Nov 17 '11 at 17:24

Employed Russian

199,314
34
295
362

You have no idea, but I wish I could upvote this even more. My question stemmed from being unable to load `libmysqlclient_r` used in a Python cheese shop package (MySQL-Python) despite it compiling/building just fine. `LD_DEBUG=libs ldd` was my life safer. It transpires that the path file saved in `/etc/ld.co.conf.d` didn't end in `.conf` and my `/etc/ld.so.conf` file specifies: `include ld.so.conf.d/*.conf`. So the `/usr/lib/mysql` folder was never being searched. – Kev Nov 24 '11 at 02:02

score 1 · Answer 2 · answered Nov 17 '11 at 16:21

Are these dependency filenames and paths (/usr/lib/mysql/libmysqlclient.so.16) baked into the shared library binary?

Yes, they can be and often are. The keyword here is -rpath. However, ld.conf also has its say. The whole system is quite complex, unfortunately.

How are shared library dependency paths determined on Linux?

2 Answers2