This is just a reminder to myself, in case I will need it in the future.

Some days ago I was discussing this interesting problem: how to manage applications that need different versions of some core libraries (e.g. glibc)?

As example, if we have an application that needs a shared library with soname reallyneedthis.so.1, I can package the application together with that library, but it is not that simple for core libraries.

Then, a few days later, I used LD_LIBRARY_PATH to test a custom version of ModemManager1 and I light switched on in my head. Can we use LD_LIBRARY_PATH for core libraries?

Unfortunately it is not that easy, because some absolute paths are hard-coded at link time2 (e.g. ld-linux.so.2 from glibc) and there might be other problems too.

The easiest solution would require to build the application with the new/old glibc (or with something like rtldi) using the –dynamic-linker flag (ELF executable). However rebuild is not an option, usually, and then things get trickier. One solution would be to “instruct” the linker before running the application

$ /path/to/new/libc/ld-linux.so.2 --library-path /path/to/lib <binary>

Some articles I read suggest also the chroot solution, but I still need to see this solution better.

  1. The system was using the wrong library after installation ( see also could not find symbol X)
  2. Those static paths are the ones reported by “ldd”[↩].