On Sunday 2021-04-18 22:06, Bruce Ferrell wrote:
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
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
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.