2

I had someone tell me this, "I do know the symlinks are not used on linux when loading a library."

However, this does not seem correct to me. Too often I have had to fix broken symlinks when I have been messing around in Linux.

I can find information on symlinks, how they work, and how they are created.

I can find information on shared and static libraries, and how they work.

But I cannot find any documentation that describes the library loading process of how symlinks are used when loading libraries. Particularly when there are multiple versions of the library.

Can someone point me to documentation that describes how symlinks are used to load libraries in Linux?

Update

After some research I believe the person was implying that the .so symlinks are not used when loading a library.

Fred
  • 335

2 Answers2

3

You are unlikely to find any documentation which describes how dynamic libraries work with symlinks because these two concepts are implemented at different level of abstraction. Symlinks belong to file systems and are transparent to applications and dynamic libraries. For program a file is just file, whether it's a real file or a symlink. All inner workings are hidden inside the OS kernel.

yugr
  • 146
3

Turns out that I didn't understand the linking process to libraries.

When a library is linked to a program after it is compiled, it links to the soname (which is usually the .so.XX file, where XX is a version number) of the library, not to the .so version.

Running ldd on an application shows this:

> ldd /opt/GSix/bin/MyApplication 
linux-vdso.so.1 (0x00007ffcefff0000)
/usr/lib64/libsyslognb.so (0x00007fe1eacbc000)
librt.so.1 => /lib64/librt.so.1 (0x00007fe1eaab4000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe1ea897000)
libQt5Widgets.so.5 => /usr/local/Trolltech/Qt-5/lib/libQt5Widgets.so.5 (0x00007fe1e99f5000)
libQt5Gui.so.5 => /usr/local/Trolltech/Qt-5/lib/libQt5Gui.so.5 (0x00007fe1e9143000)
libQt5Core.so.5 => /usr/local/Trolltech/Qt-5/lib/libQt5Core.so.5 (0x00007fe1e894d000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe1e85d2000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe1e82d4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe1e80c2000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe1e7d24000)

Each of these libraries have a .so symlink version that points to the major .so.X version. But ldd shows that the application does not link to the .so version.

This makes sense because it allows multiple versions of a library to be installed on the system and each application will only load the version it needs without conflicting with other versions.

For example, your curl libraries may look like this:

16 libcurl.so -> libcurl.so.4
16 libcurl.so.4 -> libcurl.so.4.4.0
387K libcurl.so.4.4.0

16 libcurl.so.3 -> libcurl.so.3.1.0
387K libcurl.so.3.1.0

Let's say that MyApplication was linked against version 4 and YourApplication was linked against version 3.

If both applications were looking for libcurl.so, then YourApplication would fail to load because libcurl.so is a symlink to libcurl.so.4.

This is why application need to load the .so.X version and not the .so version.

Fred
  • 335
  • 1
    Close enough — my only quibble is that programs link to libraries as determined by their soname, not their major version (but the soname typically corresponds to the major version). A library’s soname can be extracted using readelf. – Stephen Kitt Mar 28 '23 at 04:21
  • @StephenKitt Thanks for the clarification. Updated to include this. – Fred Mar 28 '23 at 12:59