Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
"shared libraries that don't play well" Do tell... –  Ignacio Vazquez-Abrams Feb 27 '12 at 22:20
add comment

2 Answers

up vote 2 down vote accepted

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 piss off a few people. :)

What are you trying to do?

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.