1

I'm trying to use shared libraries that don't play well with the ld-linux-x86-64.so.2 that is found in /lib64. I don't have root access so I can't change the file in /lib64. Is there a way that I can tell my RHEL5.7 box to use a different ld-linux-x86-64.so.2? I've tried putting the path to the version that I need to use inside $LD_LIBRARY_PATH, but it gets ignored there.

I have an executable that came packaged with some shared libs. The executable mostly works with the libraries that are already found on the machine, but every once in a while crashes and points to one of the libraries that I'm using from /lib. When I add some of the libraries that came with the executable to my LD_LIBRARY_PATH, it causes segmentation faults for simple commands like 'ls' 'cp' 'ldd' A version of the ld-linux-x86-64.so.2 also came with this executable and it doesn't cause a seg fault when I run the command ./ld-linux-x86-64.so.2 --list libc.so (or the other library that causes commands to break). I wanted to be able to test out using the ld-linux-x86-64.so.2 that came packaged with the software to make sure that that took care of the issues (and didn't cause others) before going to IT and having them make changes to all of the boxes that we'll run the software on. Or if possible build the work around into my job script so that I don't have to go through the whole change request process.

One sympton of the included libc.so not playing well with ld-linux.so is when I try doing a command is as follows. cp: relocation error: libc.so.6: symbol _dl_tls_get_addr_soft, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference I am the only one that uses my machine, but my company won't give out root access to users because the way the network is set up if you've got root on one linux box you've got it on all of them.

1

3 Answers 3

6

Sorry for this "answer", i tried to put this in a comment on your question, but the spacing and the formatting are limited.

ld-linux-x86-64.so.2 is a pretty core part of your OS. It actually runs every (64 bit) dynamic application. It's not a library as much as an app itself, a handler that is called when you run an app.

Basically, when you run a dynamic app, the kernel first runs ld-linux.so (or whatever name it is for your bitsize, distro, etc). ld-linux.so then peers into your app, sees the libraries that you need, sees any hard coded paths for the libraries (e.g. rpath's) checks LD_LIBRARY_PATH, and then goes looking for all those libraries, makes sure they match bitsizes, names, what have you. It then collects all of those, loads them, and runs your app. If it can't find the libs, it doesn't run your app.

ld-linux.so can not be affected by LD_LIBRARY_PATH because it is run by the kernel, and the kernel does not load libraries like ld-linux.so does, it just has the one it's configured to run. Again, not a library, so don't use library semantics (LD_LIBRARY_PATH) to change how it's called. It does have environment variables that affect it running - see man ld-linux.so for details (besides LD_LIBRARY_PATH, LD_PRELOAD is very useful).

I'd be very interested to see what your issue is. No offense, but this seems to be an X-Y Problem. This again is a core OS piece. If it's broken, your OS would be broken. If you want to swap it out, you'd probably affect (read: break horribly) the rest of your system. Since you don't have root, I assume you're not the only one on this box, and you'd anger a few people. :)

What are you trying to do?

0

Adding another answer, because the other answer was more of a speech/rant anyway.

It seems that you have not a ld-linux.so issue, but more likely a simple library mismatch issue. Probably versions - RHEL 5 is no longer current RHEL release so is no longer cutting edge, and glibc in particular has had issues across the versions.

I would wrap your executable with a simple shell script that would set LD_LIBRARY_PATH for your special libs and then exec your app. This way your other apps (ls, cs, etc) won't be affected by those new libraries. In your script you could even use the new ld-linux.so to run your app in the script, if that helped. I'd think not, but you can test it. This way everything is isolated to the script, the new executable and the specific libraries that came with it.

0

ld-linux.so is a library loader and it is part of libc, therefore the used ls-linux.so and libc6.so need to be compatible with each other.

When a binary is started the host's ld-linux.so is being called to load all the depended libraries using rpath and LD_LIBRARY_PATH environment etc. Normally it will load libc6.so from the system and everything is fine.

However, if the software ships its own libc6.so and system's ld-linux.so loads it, and they are not compatible, then you get a crash.

A workaround is to ship your own ld-linux.so together with all the required libraries including libc6.so and then execute the binary through your custom ld-linux.so:

./ld-linux.so mybinary

The binary should also be linked with -Wl,rpath=$ORIGIN (or similar) so that ld-linux.so would look for the libraries in the directory next to the binary (otherwise it might start looking in the host's libraries which will load the system's libc6.so and then it may crash due to foreign ld-linux.so).

One may inspect the library dependencies using ldd to make sure a complete set of libraries is included:

ldd mybinary

This workaround also has limitations: ld-linux.so assumes certain Linux kernel ABI, thus they must also be compatible, but Linux kernel ABI changes less often than libc ABI, which can buy you a few years (or even decades) of compatibility.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .