Hi Conrad, Conrad Lloyd-Knight <[EMAIL PROTECTED]> wrote:
> I had posted earlier this week about gtk-gnutella crashing upon
> startup.
Did you really compile 0.92.1c now or did you compile a newer
version from CVS? AFAIK, the problem was reading from an
unitialised buffer. Thomas Schuerger found the bug and sent
a patch. I thought, you had read this so I didn't send an
explicit mail that the problem is fixed. Well, I should have.
> Coincidentally, libz.so is also in /usr/lib and so is
> included in the second case, but not in the first. There, libz.a
> from the XFree86 distribution appears to be used instead, which is
> what I think caused the segfault.
Okay, that might be pure coincidence. ATM, I don't know how you
could prevent a wrong inclusion except by fixing the order of
RPATHs and LDPATHs.
> So the crash was easily solved by recompiling with an explicit
> "-L/usr/lib" in the linking phase. My question is, should there
> perhaps be a check for this in the configure script?
There is a check. It simply depends on the order of the paths
you tell to the linker with -L. You can also use the workaround
to set LD_LIBRARY_PATH for the executable, if you cannot fix
the order due to e.g., collisions in several paths.
> It checks for X
> and gtk and makes sure those libraries are used, but there is no
> "libz-config" or libz.pc (that I'm aware of, anyway) to let configure
> know where that is.
I guess the plain reason is that nobody contributed such files -
they have to be created during the build phase, so these cannot
be static files to be shipped with libz. libz builds on a lot
more systems than e.g., gtk+ so maybe they don't like this
more or less "unix-like" solution. Not to mention, that the
concepts of pkg-config and especially bla-config are somewhat
naive and don't work on a lot of "exotic" systems. AFAIK, both don't
really fix the problem of concurrency path orders. That's
probably because it's mostly used on Linux where you install
*everything* into /usr/{include,lib,share,...}.
> Or is my system borked and "-L/usr/lib" is
> considered a default that shouldn't have to be explicitly listed?
No, it's just that having different implementations libraries
in several paths can become a PITA if you don't use one path
per package. It works quite well during the loading phase
(which allows you to keep old versions so you don't have to
recompile everything when you update a library). But it
can cause trouble if there are concurrency *.a and *.so files
in your link paths.
I'd try to hide or remove the "bad" libz.a. It's a static
library so removing it shouldn't break anything and it looks
like you don't want to build anything against it either.
--
Christian
pgp00000.pgp
Description: PGP signature
