PDA

View Full Version : How missing dependency for rpm



MarkHowells
26th June 2008, 11:48 AM
Hi All,

I'm new to Fedora, but have been using Linux for a few years now.

I need to install an rpm - originally made for RH7.2. There is no newer version available from the vendor. However, when I install using

#yum yum localinstall -t rs-api-4.5.00-00.i386.rpm

I get the following

Loaded plugins: refresh-packagekit
Setting up Local Package Process
Examining rs-api-4.5.00-00.i386.rpm: rs-api-4.5.00-00.i386
Marking rs-api-4.5.00-00.i386.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package rs-api.i386 0:4.5.00-00 set to be updated
--> Processing Dependency: libcrypto.so.2 for package: rs-api
--> Processing Dependency: libssl.so.2 for package: rs-api
--> Finished Dependency Resolution
rs-api-4.5.00-00.i386 from rs-api-4.5.00-00.i386.rpm has depsolving problems
--> Missing Dependency: libssl.so.2 is needed by package rs-api-4.5.00-00.i386 (rs-api-4.5.00-00.i386.rpm)
rs-api-4.5.00-00.i386 from rs-api-4.5.00-00.i386.rpm has depsolving problems
--> Missing Dependency: libcrypto.so.2 is needed by package rs-api-4.5.00-00.i386 (rs-api-4.5.00-00.i386.rpm)
Error: Missing Dependency: libcrypto.so.2 is needed by package rs-api-4.5.00-00.i386 (rs-api-4.5.00-00.i386.rpm)
Error: Missing Dependency: libssl.so.2 is needed by package rs-api-4.5.00-00.i386 (rs-api-4.5.00-00.i386.rpm)


However, ls -l /lib gives
...
-rwxr-xr-x 1 root root 1351056 2008-05-28 19:15 libcrypto.so.0.9.8g
lrwxrwxrwx 1 root root 19 2008-06-25 17:23 libcrypto.so.7 -> libcrypto.so.0.9.8g
...
-rwxr-xr-x 1 root root 304624 2008-05-28 19:15 libssl.so.0.9.8g
lrwxrwxrwx 1 root root 16 2008-06-25 17:23 libssl.so.7 -> libssl.so.0.9.8g
...


so why doesn't yum find the newer versions of the libs?

Also, linking libssl.so.2->libssl.so.0.9.8g doesn't help either.

Any help would be appreciated.

Cheers

Mark

scottro
26th June 2008, 11:53 AM
This happened to me with VirtualBox at one point--I gave up and installed from source.

The rpm probably has so.2 hard coded into it. With VirtualBox, the only solution at the time) I was doing what you tried, installing an older rpm on F8 or F9--in this case it was libcrypto.so.6, I believe and Fedora was up to so.7.
So, you might see if it will build from source. Of course, it's better to use the rpm when available, but unless you can find one for F9, you might be out of luck.

Another possibility, which I've never done, is rebuild the rpm after editing the spec file and changing the so.2 to what you have, but I've never tried that--or I tried it once andi t didn't work, no doubt because I missed something else in the spec file.

Hlingler
26th June 2008, 12:12 PM
The prerequisites are static and can't (or at least shouldn't) be changed - newer versions of libraries will cause this type of error. Re-compiling from source code may not work for the same reasons (the *-devel add-ons to the prerequisites will also be of higher revision).

You can try:
> Find a compatability package that provides the older libraries. Good luck on that one going from libssl.so.2->libssl.so.0.9.8g
> Manually linking as you did will not fool yum, but you can force the install with rpm using the '--nodeps' switch. And hope that the newer library doesn't break the program. Note that '--force' and '--nodeps' installs are always at your own risk.
> Scour the internet for a newer package 'rs-api'. Start with rpm.pbone.net, rpm.find.net, and rpmseek.com.

Good Luck,
V

MarkHowells
26th June 2008, 12:39 PM
Hi,

trying

#yum localinstall --force ...

gives

Command line error: no such option: --force

am I using an out-of-date version of yum?

Hlingler
26th June 2008, 12:56 PM
No, not yum - yum cannot be forced, fooled, or otherwise manipulated into doing stuff like this.

You must force/no-deps install with the rpm program (that yum depends on). In this case, assuming that you run the command (as root user) while inside the folder where that RPM package is located:
rpm -Uvh --nodeps rs-api-4.5.00-00.i386.rpm

The '--force' switch is not needed in this case.

"And hope that the newer library doesn't break the program. Note that '--force' and '--nodeps' installs are always at your own risk."

V

MarkHowells
26th June 2008, 01:04 PM
Ahh. Sorry about that - was being a bit blonde...

I do now have the rpms installed. The next problem is that I have to set LD_ASSUME_KERNEL=2.4.19 to fix the app - otherwise I get an error
"version GLIBC_2.0 not defined in file libc.so.6 with link time reference"

Sadly this breaks the app elsewhere with

"error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory"

And this is exactly where I got to installing on Ubuntu Linux too. I'm guessing that the libpthread.so.0 installed uses the newer api. Any ideas on how to resolve this...

Thanks very much for your replies so far..

Cheers

Mark
Cheers

Mark

Hlingler
26th June 2008, 01:28 PM
What release of Fedora is this?

I don't know why it should not find that file. You should have that library: libpthread.so.0. It's part of the glibc package which must be installed. Try:
locate libpthread.so.0

Should return:
/lib/libpthread.so.0

In addition to that other environment variable, you can also try:
export LD_PRELOAD=/lib/libpthread.so.0

before running the app. See if that helps

V

P.S. I might also mention that I've had reasonable success once or twice using the manual link "trick" from a non-existant older library to a newer, extant one. This just appeases the program when it runs, giving it the target that it's looking for, but it won't fool yum (or rpm) because the manual sym-link that you make is not in the RPM DataBase. Whether or not the program actually runs using the (link to the) newer library is another matter entirely. I've also had one or two cases where this trick was... much less than successful.

MarkHowells
26th June 2008, 01:41 PM
This is Fedora 9... I Got identical results with Ubuntu too...

When I run

ls -l /lib

I get

...
-rwxr-xr-x 1 root root 131332 2008-05-05 13:56 libpthread-2.8.so
lrwxrwxrwx 1 root root 17 2008-06-25 15:44 libpthread.so.0 -> libpthread-2.8.so
...

Setting LD_PRELOAD as you suggested gives

ERROR: ld.so: object '/lib/libpthread.so.0' from LD_PRELOAD cannot be preloaded: ignored.
./lmgrd: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

I wasn't aware of LD_PRELOAD... Using LD_DEBUG I can see that ld considers this file too...

# LD_DEBUG=all LD_ASSUME_KERNEL=2.4.19 ./lmgrd
4094:
4094: file=/lib/libpthread.so.0 [0]; needed by ./lmgrd [0]
ERROR: ld.so: object '/lib/libpthread.so.0' from LD_PRELOAD cannot be preloaded: ignored.
4094:
4094: file=libpthread.so.0 [0]; needed by ./lmgrd [0]
4094: find library=libpthread.so.0 [0]; searching
4094: search cache=/etc/ld.so.cache
4094: search path=/lib/tls/i686/sse2:/lib/tls/i686:/lib/tls/sse2:/lib/tls:/lib/i686/sse2:/lib/i686:/lib/sse2:/lib:/usr/lib/tls/i686/sse2:/usr/lib/tls/i686:/usr/lib/tls/sse2:/usr/lib/tls:/usr/lib/i686/sse2:/usr/lib/i686:/usr/lib/sse2:/usr/lib (system search path)
4094: trying file=/lib/tls/i686/sse2/libpthread.so.0
4094: trying file=/lib/tls/i686/libpthread.so.0
4094: trying file=/lib/tls/sse2/libpthread.so.0
4094: trying file=/lib/tls/libpthread.so.0
4094: trying file=/lib/i686/sse2/libpthread.so.0
4094: trying file=/lib/i686/libpthread.so.0
4094: trying file=/lib/sse2/libpthread.so.0
4094: trying file=/lib/libpthread.so.0
4094: trying file=/usr/lib/tls/i686/sse2/libpthread.so.0
4094: trying file=/usr/lib/tls/i686/libpthread.so.0
4094: trying file=/usr/lib/tls/sse2/libpthread.so.0
4094: trying file=/usr/lib/tls/libpthread.so.0
4094: trying file=/usr/lib/i686/sse2/libpthread.so.0
4094: trying file=/usr/lib/i686/libpthread.so.0
4094: trying file=/usr/lib/sse2/libpthread.so.0
4094: trying file=/usr/lib/libpthread.so.0
4094:
./lmgrd: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

I'm guessing that the LD_ASSUME_KERNEL value means that the loader has no viable pthread library...

Hlingler
26th June 2008, 01:50 PM
Then I'm personally out of ideas (and techno-magical tricks), and those new errors are now beyond my knowledge. Sorry.

Your best bet at this point may be to try re-compiling the application from source code, as scottro originally suggested, or maybe try to find a newer package somewhere.

Good Luck,
V

MarkHowells
26th June 2008, 01:54 PM
Well, Thanks for your help. Sadly neither source nor newer versions are available, so I'm having to continue to battle on. This is a fairly major app. and quite modern - but I think that the company's focus is rather more on M$ platforms than Linux :(

Cheers

Mark