On Tue, 05 Nov 2002 11:41:28 GMT John Pettigrew wrote:

In a previous message, zentara wrote:

...

On Mon, 04 Nov 2002 20:57:01 GMT John Pettigrew wrote:

...

jpilot complains (when I try to install the rpm) that it needs libcrypto.so.0. [snip] The relevant file is present in /usr/lib (symlink to libcrypto.so.0.9.6)

Yeah, this happens with alot of apps.

Go into /usr/lib and make symlinks

But, as I said, there seems to be such a file already. Should I replace it? Why is the system not picking this up?

Maybe try doing a ldconfig to update the ld cache? Maybe the app is "hardwired" to look for the lib in /usr/local/lib instead of /usr/lib. Try making symlinks in /usr/local/lib then do a ldconfig. -- use Perl; #powerful programmable prestidigitation

zentara [Tue, 5 Nov 2002 06:21:12 -0500]:

Yeah, this happens with alot of apps.

Well, but correctly solving it ain't that easy :)

Go into /usr/lib and make symlinks @libcrypto.so

No, this is provided by openssl-devel.rpm and in nearly every case only needed for compiling an application/binary.

@libcrypto.so.0

Is useless, as libcrypto.so.0.9.6 of 8.1 has an internal name (the so called soname of libcrypto.so.0.9.6.

The apps look for the simple name of the lib instead of the full name.

What apps look for are the names recorded in special fields of the binary, the so called DT_NEEDED. A ldd on the binary will show you those names and what library it resolves to. In the case of libcrypto creating the symlink is *wrong*. If you do a 'objdump -p /usr/lib/libcrypto.so.0.9.6', you'll find in the output this: SONAME libcrypto.so.0.9.6 This is the name that gets written into DT_NEEDED of the application. The contents of this Field may be viewed by ldd or by 'objdump -p'. If this fresh jpilot RPM lists libcrypto.so.0 as needed, it has been compiled on a system where libcrypto.so points to the wrong library! Creating random symlinks won't cure the root cause. Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: pth@t-link.de

On Wednesday 06 November 2002 10.46, John Pettigrew wrote:

In a previous message, Philipp Thomas wrote:

...

If this fresh jpilot RPM lists libcrypto.so.0 as needed, it has been compiled on a system where libcrypto.so points to the wrong library! Creating random symlinks won't cure the root cause.

OK, that's great info, thanks. But, the rpm was compiled on my system (using checkinstall) - SuSE 8.1. So, what do I need to do to stop this complaint?

It seems insane to use major, minor *and* revision number as soname. Even a minor bugfix update would require a lot of rebuilding, or to keep the entire version number intact. That doesn't seem like a good use of version numbers. In any case, Quick fix: rebuild SuSE's openssl, and edit openssl.spec to add libcrypto.so.0 on the "Provides" line. That should make rpms dependency checker shut up. If you like I've built rpms for 8.1 since I had the same problem with ymessenger.rpm. Note that it's rpm that's complaining, not the dynamic linker.

Anders Johansson [Wed, 6 Nov 2002 14:44:55 +0100]:

On Wednesday 06 November 2002 10.46, John Pettigrew wrote:

It seems insane to use major, minor *and* revision number as soname. Even a minor bugfix update would require a lot of rebuilding, or to keep the entire version number intact. That doesn't seem like a good use of version numbers.

Complain to the openssl folks, they must have had a reason.

In any case, Quick fix: rebuild SuSE's openssl, and edit openssl.spec to add libcrypto.so.0 on the "Provides" line. That should make rpms dependency checker shut up.

Yes, with a hack like that it would work, but that's just papering over the real problem. If done right, rpm *will* find what a package needs/provides. With 'AutoReqProv: on' in the spec file, rpm should figure out itself, what a package provides or needs.

Note that it's rpm that's complaining, not the dynamic linker.

And it's IMNSHO most probably checkinstall that got the requires wrong. Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: pth@t-link.de

Anders Johansson [Wed, 6 Nov 2002 20:14:52 +0100]:

On Wednesday 06 November 2002 19.16, Philipp Thomas wrote:

...

And it's IMNSHO most probably checkinstall that got the requires wrong.

checkinstall uses rpm's find-requires, which in turn uses ldd to see which libs are needed. IMVHO it must be ld that gets it wrong.

Nope, I think there's something fishy with the openssl package which I'll check tomorrow. libcrypto has a soname of libcrypto.so.0.9.6. There are two reasons why this is so. Either no soname is passed to the linker, in which case the library name is used, or it's explicitly given. openssl *also* provides the symlink libcrypto.so.0, pointing to libcrypto.so.0.9.6. The most interesting thing would be what jpilot has in its DT_NEEDED fields. John, could you please run 'objdump -p jpilot' and post the output (the lines beginning with NEEDED would suffice)? At least the jpilot 0.99 in our source RPM has no configuration option for libcrypto and AFAICS, configure does not search for libcrypto. So I'm wondering where the need for libcrypto is coming from. John, which version of jpilot and pilot-link did you use (preferably with URL)? I'd like to check where the requirement for libcrypto is coming from. Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: pth@t-link.de

Anders Johansson [Thu, 7 Nov 2002 01:38:30 +0100]:

I'm sorry, but exactly what are you saying "Nope" to here?

OK, I was a bit too terse. That nope meant for ld doing something wrong.

It's explicitly given.

OK, so it's done on purpose. Any way, a binary linked to a dynamic library will have the soname recorded in it's DT_NEEDED fields, so in this case jpilot (or whichever program needs libcrypto) should have libcrypto.so.0.9.6 recorded, so I'm wondering where the requirement for libcrypto.so.0 is coming from. Seems to call for some testing. Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: pth@t-link.de

John Pettigrew wrote:

In a previous message, Philipp Thomas wrote:

...

openssl *also* provides the symlink libcrypto.so.0, pointing to libcrypto.so.0.9.6.

The problem was that the version from the SuSE 8.1 DVD didn't (at least, not in the rpm listing I saw in YaST) - it only provided libcrypto.so.0.9.6. The version Anders built *did* also provide libcrypto.so.0.

...

John, could you please run 'objdump -p jpilot' and post the output

Thanks for the new command "objdump"

"objdump: jpilot: No such file or directory"

Run as root.

"ltrace" is also a helpful binary to spot missing libs in a program. Similar to "strace". However, be prepared for a lot of output. As root or user - "/usr/bin/ltrace jpilot" ltrace(1) ltrace(1) NAME ltrace - A library call tracer 73 de Donn Washburn __ " http://www.hal-pc.org/~dwash " Ham Callsign N5XWB / / __ __ __ __ __ __ __ 307 Savoy St. / /__ / / / \/ / / /_/ / \ \/ / Sugar Land, TX 77478 /_____/ /_/ /_/\__/ /_____/ /_/\_\ LL# 1.281.242.3256 a MSDOS Virus "Free Zone" OS Email: n5xwb@arrl.net Info: http://www.austinlug.org

John Pettigrew [Fri, 08 Nov 2002 10:41:44 GMT]:

Which is odd - no reference to libcrypto at all!

Like I thought.

libexpense.so.0 libkeyring.so.0 libsynctime.so.0

I'd guess it's libkeyring.so.0 that needs libcrypto. You could check by running 'objdump /usr/lib/libkeyring.so.0', assuming libkeyring.so.0 is in /usr/lib. I guess I'll have to download the sources myself and try to compile them in order to solve this mystery. Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: pth@t-link.de

On Monday 11 November 2002 15:35, John Pettigrew wrote:

Yup, it lists libcrypto.so.0 in its NEEDED section. Still doesn't explain why it's not found, though! The only odd thing that struck me is that libkeyring is in /usr/lib/jpilot/plugins, but I doubt this would have an effect.

The *really* odd thing is that when I built the package (on a stock SuSE 8.1) I got libcrypto.so.0.9.6, as would be expected. Exactly how did you build the package? Anders

In a previous message, Philipp Thomas wrote:

...

In any case, Quick fix: rebuild SuSE's openssl, and edit openssl.spec to add libcrypto.so.0 on the "Provides" line. That should make rpms dependency checker shut up.

Yes, with a hack like that it would work, but that's just papering over the real problem.

Well, it worked for me! I downloaded the rpm that Anders had altered and I no longer get the spurious warning about libcrypto. If there's a better way, great, but I'm not being pestered by YaST any more :-) Thanks to all for the help with this! John -- John Pettigrew Headstrong Games john@headstrong-games.co.uk Fun : Strategy : Price http://www.headstrong-games.co.uk/ Board games that won't break the bank Knossos: escape the ever-changing labyrinth before the Minotaur catches you!