Installing two versions of libraries concurrently?
Posted by cleeland on Thu 6 Oct 2005 at 12:17
To be more specific, I am saddled with running an old version of a piece of commercial software that does not work with the latest-and-greatest glibc (2.3.5+). The most recent version I *know* works is 2.3.2.ds1-22. I know this because I actually let apt-get upgrade my libc recently, and that commercial software broke. I had to step back to 2.3.2.ds1-22.
Another ideas I've had is to move the 2.3.2.ds1-22 version of the library into a different directory, and wrap my commercial software with a script that uses LD_LIBRARY_PATH to insure that the different directory gets searched first. I know it'll work, but it's hacky, and still doesn't address my system's notion of what, exactly, is installed.
Please--no rants against the commercial software. There is no viable open-source alternative to it.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
Incidentally, I tried implementing the solution where I moved the old version of the libraries to a different directory and using LD_LIBRARY_PATH, but it didn't work. The executable for the application is setuid, and I haven't figured out how to write a wrapper around the real executable such that ld.so honors LD_PRELOAD or LD_LIBRARY_PATH when the executable is setuid.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
To be a little more specific, I initially force-installed the *same* version of the library to a different directory with the intention of wrapping my software's executable with a script that would set LD_LIBRARY_PATH to point to that directory. Through a bit of luck poking around in google, though, I found that other people had encountered similar problems and somebody had concocted a very small shared object that could be LD_PRELOADed to make modern versions of the library conform to the warped view of the library that the commercial software has. So, I wiped out the other-dir installation of the library and used this shared object.
Then I embarked on a new adventure b/c the software executable is setuid, which means that LD_PRELOAD and LD_LIBRARY_PATH get ignored. I tried making my wrapper script setuid, but Debian turns off setuid scripts by default.
I ended up installing perlsuid and writing a perl script wrapper that's setuid, and inside it sets the ruid to the euid, at which point, when it execs the commercial software executable, LD_PRELOAD gets honored b/c the exec system can't tell that anything is running setuid.
Much more work than it should have been. If I were a Real Man, I'd turn this into a debian package that I could install, but I don't know if I have the stamina for that. :-(
[ Parent | Reply to this comment ]