On 4/18/21 12:11 PM, L A Walsh wrote:
On 2021/04/18 02:06, Andreas Schwab wrote:
On Apr 18 2021, L A Walsh wrote:
> why won't the apps still run without
Um...when I try to run those apps they don't work
with the newly installed library:
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
If there is a way that makes them work
without needing a new version, say of 'ls' (coreutils),
please let me know. This isn't a new issue for me.
I've seen similar errors before
How can I make this setup work such that I
don't get the above error, as getting an error such as above doesn't allow the
program to work on my machine.
The C library, glibc, is I'm sure you know, a VERY low level library and it winds
through nearly everything... All of the C standard functions are implemented in that
well as most of the ancilliary C functions like name resolution (DNS etc)
When the app originally compiled it had one set of symbols that are in the old libraries
and they were used by the linker to tell the compiled binary how to find that function in
the library that was installed at the time.
The new library has a new set of symbols, and as the error points to, some no longer exist
or are renamed in the new version. In any case,the compiled and linked binary can't
it's required functions in the new library.
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... They don't
libraries to work that way, but they're bigger on disk.
The one thing you CAN try is is a somewhat obscure thing, and you still need to have the
old libraries to make it work: The LD_PRELOAD "trick":
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.