| View previous topic :: View next topic |
| Author |
Message |
TheJabberwokk
Apprentice
Joined: 13 Aug 2002
Posts: 196
Location: Gloucester
|
 Posted: Wed Apr 16, 2003 4:36 pm Post subject: glibc compatibility |
 |
|
| I there any way to run proprietary programs that were designed for older glibc? or to have two versions of glibc on one system? |
|
| Back to top |
|
 |
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Wed Apr 16, 2003 9:19 pm Post subject: Re: glibc compatibility |
|
|
| TheJabberwokk wrote: | | I there any way to run proprietary programs that were designed for older glibc? or to have two versions of glibc on one system? |
First I'd be curious what app you're trying to run? Also, what libc is the old binary, and what is the new one?
Yes, you can get old bin's going. It all depends on how the bin was linked, versions of libc involved, etc. You may very well be able to get by just by adding the old libs the binary uses, but you'd need to be careful. What follows ain't a good solution if you're unable to get by just adding the old libs. I figured this out at work with filemaker server- it was compiled against 2.2.4 (IIRC), and the rh7.3 system it runs on is 2.2.5.
First off, for simple bins, you can actually write a libc wrapper that basically maps the binary's old libc calls to the new libc, but if that bin forks/exec's you will have problems. I don't think there is a way to propagate LD_PRELOAD through forks/execs, aside from possibly mapping/overriding the fork/exec commands. Basically if it uses fork/exec's (daemons), time for a different attempt.
The other alternative, which I don't like too much but it works is you grab from the old libc, ld-linux and whatever libs the binary needs (gotten via ldd). From there, you can either create a true jailroot for the prog/daemon, or you can dump the libs to some directory that isn't likely to be touched by any program.
I prefer the later for simplicity- from there (assuming you have all the needed libs), you can do this (note, $path = path to the dir the old libs are stored in):
/$path/ld-linux.so --library-path $path --inhibit-rpath /lib $binary
This will get it up and running- this is basically the setup I use for filemaker. Added, while you have the annoyance of multiple glibcs loaded, it (in my experience) quite stable- no problems with it, aside from filemaker being a crappy program/daemon.
Either way, it's nasty and not exactly elegant- if its work related I'd badger them into upgrading it, or contact the company for a new binary (if possible... probably pie in the sky.) |
|
| Back to top |
|
|
TheJabberwokk
Apprentice
Joined: 13 Aug 2002
Posts: 196
Location: Gloucester
|
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Thu Apr 17, 2003 2:18 am Post subject: Re: SOFTIMAGE for linux |
|
|
The issue with SIGRTMIN I don't know much about- the developers of XSI would have to weigh in on it.
The comment about XSI being compiled to run w/ glibc 2.2 (opposed to gentoo's 2.3 default) makes me doubt it's just SIGRTMIN being whacky though...
One question I should've asked in hindsight, what does the binary output/do when it attempts to loads up? |
|
| Back to top |
|
|
TheJabberwokk
Apprentice
Joined: 13 Aug 2002
Posts: 196
Location: Gloucester
|
| Posted: Thu Apr 17, 2003 3:15 am Post subject: output |
|
|
output
| Quote: | $ tcsh
Softimage/XSI-EXP_3.0> source .xsi_EXP_3.0
Softimage/XSI-EXP_3.0> xsi
Softimage/XSI-EXP_3.0> |
|
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Thu Apr 17, 2003 4:14 am Post subject: |
|
|
| Have you tried to strace it? |
|
| Back to top |
|
|
|
Portage & Programming
