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

["Gene C." <genec ieee org>]

A couple of comments (based on my having problems with libjpeg):

1. I have both gnome and kde installed.  Now kde wants some modifications
to your profile to add their execution directory to the PATH and to add
LD_LIBRARY=/usr/local/kde/lib

It is this last one that got me since kde includes "61" of libjpeg and no
matter what I did to install into the regular spot, I was getting errors.

My fix was to create (actually extend) my modified versions of startx,
xinitrc and Xclients so that the the PATH is modified and the LD_LIBRARY is
set ONLY when I am starting kde.  Works fine and it got rid of my problems.

BTW, a modified Xclients allows me to select and run whichever
windowmanager I want to run at the moment (without needing to edit
something).  If this is of interest, I can upload it wherever or post it to
this list (sorry, I do not have a web or ftp site).

2.  The "current" snapshot rpm's look good (yes, some stuff is still broken
but it installs ok and the source I have tried to compile did so).

3. The ./configure below DOES NOT WORK!  (at least with the source rpm from
www.labs.redhat.com/pub/gnome/support).  However, both the binary is OK and
the src.rpm will compile properly and is level "62" as advertised (once I
fixed my little problem described above).

Gene






At 07:21 PM 5/15/98 -0400, Steve Dunham wrote:
>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
>
>
>-- 
>         To unsubscribe: mail gnome-list-request@gnome.org with 
>                       "unsubscribe" as the Subject.
>
>