This site is now 100% read-only, and retired.

Installing two versions of libraries concurrently?

Posted by cleeland on Thu 6 Oct 2005 at 12:17

Tags:
I'm trying to figure out the best way to install two versions of a library .deb concurrently. I know how to do this with rpm, but can't figure out a way to do this with dpkg. I've looked at dpkg-divert, but that makes me specify each individual file, so it's kind of a pain. Plus, I would have to set up the diversion, install one, then remove the diversion, then install the other, so my system would still only think that I had one version installed.

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.

 

 


Re: Installing two versions of libraries concurrently?
Posted by ajt (204.193.xx.xx) on Thu 6 Oct 2005 at 13:10
[ View Weblogs ]
The AMD64 version of Debian installs 32-bit libraries in a chroot, and then runs 32-bit software inside the chroot. Hacking the library path, as suggested, is the other obvious solution.

--
"It's Not Magic, It's Work"
Adam

[ Parent ]

Re: Installing two versions of libraries concurrently?
Posted by cleeland (209.74.xx.xx) on Thu 6 Oct 2005 at 14:54
I had thought about using a chroot jail, but figured I would also end up having to duplicate the dpkg database and tons of other stuff in order to get it to work properly.

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 ]

Re: Installing two versions of libraries concurrently?
Posted by deego (24.197.xx.xx) on Thu 6 Oct 2005 at 14:34
You said it does not work with the newer version. Did it just complain about not finding the right version? In that case, ln -s Lib-new.so lib-old.so did the trick for me once, and the software works fine for me, I don't know how bad a kludge this was...


[ Parent ]

Re: Installing two versions of libraries concurrently?
Posted by Anonymous (212.248.xx.xx) on Thu 6 Oct 2005 at 14:53
"update-alternatives" could help you, even though I never actually tried it with a library. It's that nice wonderful tool that allows you to run 98765 versions of the same program avoiding "ln" headaches.

[ Parent ]

Re: Installing two versions of libraries concurrently?
Posted by Anonymous (193.2.xx.xx) on Tue 11 Oct 2005 at 14:07
Yes, *programs*, but not libs.

[ Parent ]

Re: Installing two versions of libraries concurrently?
Posted by Anonymous (213.164.xx.xx) on Wed 12 Oct 2005 at 10:59
What did you decide on this?

[ Parent ]

Re: Installing two versions of libraries concurrently?
Posted by cleeland (209.74.xx.xx) on Wed 12 Oct 2005 at 15:42
I gave up on dpkg and the like and went with a hack. It was easier. dpkg is just broken with respect to having two versions of the same package installed simultaneously. Trying to do so creates havoc in the dependency system and makes your life a living hell.

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 ]