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

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

I have both KDE and GNOME installed in my system and I would love to see how
you corrected the problems.  Could you please send me your files?  I would
really apprecaite it.  Thanks

Nathan Alonzo Smith	
TSX-5 SpaceCraft Engineer


> -----Original Message-----
> From:	Gene C. [SMTP:genec@ieee.org]
> Sent:	Sunday, May 17, 1998 3:12 PM
> To:	Steve Dunham; Marc Ewing
> Subject:	Re: RH shared library issues (Re: libjpeg problems)
> 
> 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.
> >
> >
> 
> 
> -- 
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.