Sign up ×
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 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 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 also came with this executable and it doesn't cause a seg fault when I run the command ./ --list (or the other library that causes commands to break). I wanted to be able to test out using the 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 not playing well with is when I try doing a command is as follows. *cp: relocation error: symbol _dl_tls_get_addr_soft, version GLIBC_PRIVATE not defined in file 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

2 Answers 2

up vote 3 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. 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 (or whatever name it is for your bitsize, distro, etc). 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. can not be affected by LD_LIBRARY_PATH because it is run by the kernel, and the kernel does not load libraries like 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 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

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

It seems that you have not a 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 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

Your Answer


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.