Re: gnome-libs compilation problems
- From: John Kennedy <jk csuchico edu>
- To: dms22 cam ac uk
- Cc: GNOME <gnome-list gnome org>
- Subject: Re: gnome-libs compilation problems
- Date: Mon, 18 Jan 1999 09:19:18 -0800 (PST)
[Dave <dms22@cam.ac.uk>]
> I'm trying to compile the cvs version of gnome-libs and have the
> following problem. Everything works fine until gtk-xmhtml, which
> always comes up with this output: ...
> ... undefined reference to `uncompress'
> ... undefined reference to `compress'
Not in FAQ, but a FAQ. Many people think it is though. (: Since
I asked that last, I'll repost my conclusion. As someone already
suggested, just nuking /usr/X11R6/lib/libz.a after X11R6 has rebuilt is
a quick and dirty way to solve your problem.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>From warlock Mon Jan 11 12:14:49 1999
To: GNOME <gnome-list@gnome.org>
Subject: Re: zlibish problems with cvs gnome-libs
[Gleef <dzol@virtual-yellow.com>]
> This is certainly a Frequently Asked Question, but it doesn't appear
> to be in the FAQ. Many distributions stash an old copy of libz in
> /usr/X11R6/lib. ...
As I said I would in one of my earlier messages, I recompiled
XFree86-3.3.3 after defining HasZlib to YES in config/cf/xf86site.def.
It happily picked up the dynamic libz (from zlib-1.1.3 in my case,
configured with --prefix=/usr so you don't have to mess with X to get
it found easily) and appears to be using it quite happily.
Defining HasZlib tells X that you already have one and it doesn't
have to make its own subset (with the same name) from what I could find.
I was a little worried it might be something like `xv' that was
configured with Imake that might have slipped it in there, but just
changing the HasZlib in X made it disappear.
GNOME happened to be the first program I compiled that was using X
and compression in the same package that managed to have /usr/X11R6/lib
instead of my provided library search path. That made things more fun. (:
If you can't recompile from sources, just gzip or delete the thing.
If it was dynamic I'd worry a little bit more, but compressing the static
library isn't going to hurt anything after the build.
> ... The solution is to remove all old versions of libz, so that you
> are left with only the libz from zlib version 1.1.2. Then rerun
> ldconfig.
In my case, there was no dynamic libz.so, just a libz.a, even though
the rest of X11 was compiled and had dynamic libraries. That helps
libz.a slip under the radar of a lot of people.
> This should not cause problems with programs linked against the old
> libz, all the ones I've tried or heard about will happily run with
> the newer libz.
Since that was probably intended by X to just be used by it for its
fonts and is static to boot, that shouldn't hurt. In any case, X seems
happy using the libz from zlib-1.1.3. It looks like it gets used for
fonts, so I probably would have tripped over any problems by now.
--- john
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]