On Sunday 2021-04-18 22:06, Bruce Ferrell wrote:
ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference ----
When the app originally compiled it had one set of symbols
ls does not require "_dl_fatal_printf".
This is part of the reason that very "elemental" *IX (Linux, UNIX etc) programs like ls, ps, etc used to be installed in a staticlly linked version...
That is a red herring. The error stems from the dynamic linker unable to combine two versions of libc. If you were to attempt the same with a static link, that would equally fail. Static linking mode just doesn't fix stupid linking attempts in the first place.
To make a long story short, the linker universally sticks a hook into programs that looks for the environment variable LD_PRELOAD, and if present, uses the libraries found there before looking at LD_LIBRARY_PATH to resolve library loading.
No, not really, especially not for the case of dynamicly-linked executables. Analysis of LD_PRELOAD/LD_LIBRARY_PATH happens by ld-linux.so, which is not a hook but a program in its own right.