To: gnome-list@gnome.org
Subject: RH shared library issues (Re: libjpeg problems)
From: Steve Dunham <dunham@cps.msu.edu>
Date: 15 May 1998 17:27:54 -0400


This is CC'd to redhat-devel-list, followups on non-gnome shared
library issues should probably be directed there.


Samuel Gabor <immortal@vector.nevtron.si> writes:

> I finally managed to install binary .rpms from 14. 5. 1998.

> The problem is I get this when trying to view a JPG file with ee:

> Wrong JPEG library version: library is 61, caller expects 62

> XV and gmc just core dumps.

> I installed libjpeg-6b-1a.i386.rpm (the newest?). Older versions don't
> work either. 

Yup, apparently someone has seen fit to release a copy of the
libjpeg-6b library, which is NOT binary compatible with libjpeg-6a,
with a soname of libjpeg.so.6.  Apparently whoever is compiling the
RPM snapshots is using this.  Further, there is a copy of libjpeg-6b
in contrib with an soname of libjpeg.so.7, which won't be loaded
against the snapshot binaries at runtime.

Given the source of the RPM Gnome snapshots, I worry about whether
RedHat 5.1 will ship with libjpeg version 6b having a soname of
libjpeg.so.6, making it incompatible with both programs compiled on
Red Hat 5.0 and on Debian Linux.

(I suspect the Debian version will have a soname of libjpeg.so.6b,
just like version 6a had a soname of libjpeg.so.6a, because it wasn't
compatible with version 6.)


Red Hat could use a little work with respect shared libraries.  Some
of the shared libraries (e.g. libpng) depend on other libraries
(e.g. libz) but don't explicitly reference them.  This can cause
version mismatches when linking that are undetectable until runtime,
when the program crashes for no reason.  


Some of their libraries depend on other libraries without explicitly
referencing them - inviting version mismatches when linking.

This practice has caused me all sorts of problems with the snapshot
RPMs of Imlib.  Imlib uses libjpeg and libpng, but doesn't reference
them, so the references aren't created until you link your program.
If Imlib is compiled on a system with one version of libjpeg and the
program using Imlib is linked on a system with another version of
libjpeg, you will not notice the problem until late into runtime.  A
lot of the gnome libraries (except libmico) seem to suffer from this
problem.

The XFree86 from contrib is linked correctly, I'm unable to check the
version shipped with RH 5.0, since my install tree has the new version
merged in.  The distributed version of libncurses, libslang, and
libnewt are linked correctly, but others, like libpng are not.

A way to check these things is to run "ldd" on the shared library.  A
library should, at the very least, reference libc.so.6 if it uses any
libc functions (or include files).  Also, as a matter of policy, any
shared lib should reference all libraries on which it is directly
dependent.  These types of references can be added by appending
e.g. -lz to the link line for the shared library.  (This is a
requirement of all Debian packages, BTW.)


Also, and unrelated problem: Red Hat 5.0 has two non-identical copies
of libz.a.

Should I submit these types of bugs to Red Hat's bugs address, or will
they fall on deaf ears?  (This type of quality control is important to
me - I would really like to see Red Hat become as good as Debian in
this respect.)


One other idea worth mentioning: Debian codes the library .so version
in the package name, so that libpng.so.0 is contained in the libpng0
package and libpng.so.2 is contained in the libpng2 package.

This isn't _necessary_ on Red Hat, since the user can have both
libpng-0.96 and libpng-1.0 installed at the same time, but it might
make life easier.  (There is not way to specify both versions of
libpng in a comps file.)


Steve
dunham@cps.msu.edu

-- 
To unsubscribe:
mail -s unsubscribe redhat-devel-list-request@redhat.com < /dev/null