Re: RH shared library issues (Re: libjpeg problems)

[Marc Ewing <marc redhat com>]

Steve Dunham <dunham@cps.msu.edu> writes:
> 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.

As far as I know, this is the way the jpeg library is shipped in
source.  We try not to go mucking with the authors selection of
soname as that can cause confusion.  If you want a different
soname, take it up with the authors.  The jpeg case is particularly
weird because the authors seem to ignore the soname as a feature
for "checking" versions, and implement it themselves in the library,
with the result that you can run a program that linked correctly,
but it will complain when run.  I agree it is all gross.

> 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.

Probably will.

> (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.)

Does Debian arrange this with the jpeg authors, or do they just
do it unilateraly?

> 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 reason you see this in the GNOME stuff is that it uses libtool
and currently shared library "dependencies" like you are talking
about disabled in libtool.

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

This should be fixed in 5.1.  Feel free to blow away the one in
/usr/X11R6/lib.

> 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.)

All bugs should go to bugs@redhat.com.  We do read them.

> 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.

We do that occasionally when we need to keep an old version of a
library in a shipping Red Hat Linux release.

-Marc