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

["Smith, Nathan A., Capt." <smithna Comanche plk af mil>]

Ok, 

This provides a lot of information on the problem, but for slow people like
me - I don't see how I can actually fix the problem on my machine.  Any
takers???

Nathan

> -----Original Message-----
> From:	Steve Dunham [SMTP:dunham@cps.msu.edu]
> Sent:	Friday, May 15, 1998 3:28 PM
> To:	gnome-list@gnome.org
> Subject:	RH shared library issues (Re: libjpeg problems)
> 
> 
> 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 gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.