I just followed the advice here:
as an Android related program has been complaining about glibc-2.29
Everything seemed to compile and now in the
/opt folder there you can see a folder for the newly installed library:
$ ls /opt/glibc-2.29/ bin etc include lib libexec sbin share var
The original program however, even after a reboot, is still producing its error message:
.....because /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found
I am thinking that the last line of the solution:
possibly works in Centos 6 but not in Debian. If I type
env | grep LD after a reboot it does not find anything. I just checked my history, and did change 2.14 to 2.29 before running that.
I am running Debian 10.4 Buster. Any ideas how to make this work or fault find it?
I found that running that last line to export LD_LIBRARY_PATH inside the same terminal window before the program which needs it, makes the error go away, but it really kills everything in that terminal – whatever I enter, even
ls returns a memory access error. I can do nothing but close that terminal. It seems that Debian really does not like that LD path to be changed like that.
You can’t blindly change glibc and expect everything to cope happily. Programs that expect 2.14 will need to continue using 2.14, but programs expecting 2.29 can be set up to use that.
If you set
LD_LIBRARY_PATH you are telling the linker where to find a library. If you call 2.29 the same as 2.14 then the linker will try to link older programs with the newer library, with the unhappy consequences you’ve found.
Fortunately you can set
LD_LIBRARY_PATH just for the necessary executable, and then it won’t affect anything else: