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

[Steve Dunham <dunham cps msu edu>]

Marc Ewing <marc@redhat.com> writes:

> Steve Dunham <dunham@cps.msu.edu> writes:

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

Nope. I just checked, and it seems we are both wrong.  The upstream
version number is 62.  The correct way to compile the package is:

   ./configure --enabled-shared --enable-static --prefix=/usr

This will use libtool and a major version number of 62.

> > (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?

Debian does follow upstream sonames, unless they are broken.  I'll
file a Debian bug report against libjpeg6b.  I don't know if I should
file a Red Hat one for a package that doesn't exist yet?

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

This seems to be turned on in the Debian libtool package. The libtool
program on Debian has \$deplibs at the end of the "archive_cmds"
variable, Red Hat doesn't.

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

Not a big deal, just thought I'd mention it.  (The .so file overrides
it most of the time anyways.)

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

I'll do this.  I wasn't sure how Red Hat 

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

It's easy to arrange one instance of a library in a shipping release.

Some of use make our own interim releases. Our local install tree has
the updates, a gnome snapshot, XFree-3.3.2 and xemacs-21.0-b37 in it,
with a completely different comps file.  Red Hat makes it amazingly
easy to do this.


Steve
dunham@cps.msu.edu