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.
- The system was using the wrong library after installation ( see also could not find symbol X)
- Those static paths are the ones reported by “ldd”[↩].