Date: Wed, 8 Nov 2000 19:55:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: andrew@ugh.net.au Cc: jasone@canonware.com (Jason Evans), freebsd-hackers@FreeBSD.ORG Subject: Re: gdb & threaded application Message-ID: <200011081955.MAA24247@usr08.primenet.com> In-Reply-To: <Pine.BSF.4.21.0011061408220.47384-100000@starbug.ugh.net.au> from "andrew@ugh.net.au" at Nov 06, 2000 02:09:33 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > the first thing I'd do if I were you would be to link statically.
>
> Yep that fixed it.
In my experience, which include trying to get the JNI stuff
working with promiscuous libraries, this is generally the
result of a bug in the FreeBSD linker.
What it usually means is that you have a program linked
against a shared library that uses a function from a
different shared library, like:
prog:
main()
{
lib_1_function();
}
lib1:
lib_1_function()
{
lib_2_function();
}
And then no references to any other lib2 stuff from prog.
The linker appaers to treat this as an RTLD_LAZY rather than
an RTLD_NOW for the purposes of dependent symbol resoloution
(ELF supports linking a shared library against another shared
library, which is supposed to cause the library linked against
to come in when you link programs against the first library).
It appears that because of the RTLD_LAZY behaviou, there is
no recursion on the load, and the second order dependency
blows up, rather than getting resolved.
I tried to fix this in the rtld stuff in FreeBSD 3.x, but it
turned out that fixing the linker introduced a lot of references
that then blew up, and what looked like it might take only an
hour or so to fix blew up into something that would take a
couple of weeks to fix (and I didn't have them).
The easiest thing would be to explicitly link against the
second order dependent library, or to link the first order
dependent library statically, which will cause the symbols
to be undefined unless the second order link is forced by
the reference (this latter is what I think saved you, in
this case, FWIW).
I have also seen this (rarely), when ldconfig does not include
the library where the shared libraries are being installed, for
user supplied shared libraries. I think this is a bug, since
ldconfig is only supposed to cache hints; you would think that
it would look to the original link location to try to find the
library, but it doesn't. I've seen this most often when doing
builds of code off the net (like OpenSSL + Cyrus SASL) into
my own build environment, rather than using /usr/local/lib,
like ports wants you to. The link succeeds, but at runtime,
the library fails to load. You can see this by doing an "ldd"
on your binary, and seeing that it can't find some of the
libraries (ldd and ld.so use the same ldconfig hints, and both
use the same lookup function, which fails to do the correct
thing when looking for "not found" libraries).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011081955.MAA24247>