Server Bug Fix: LD_LIBRARY_PATH in Debian

Original Source Link

I just followed the advice here:

How to update glibc to 2.14 in CentOS 6.5

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/ version `GLIBC_2.29' not found

I am thinking that the last line of the solution:

export LD_LIBRARY_PATH="/opt/glibc-2.14/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

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:

LD_LIBRARY_PATH=/opt/glibc-2.29/lib /path/to/my/program

Tagged : / /

Leave a Reply

Your email address will not be published. Required fields are marked *