Date: Tue, 30 Jan 2001 01:09:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: arch@FreeBSD.ORG Cc: peter@netplex.com.au Subject: Re: libc_r badness Message-ID: <200101300109.SAA11860@usr07.primenet.com> In-Reply-To: <200101291834.f0TIYL957823@vashon.polstra.com> from "John Polstra" at Jan 29, 2001 10:34:21 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > One is to have -lc_r on its own pull in libc to avoid POLA for apps
> > that use ld(1) directly (doesn't work for static, no big deal). The
> > second (seperate) issue is exising dynamic binaries on people's
> > -current systems (eg: ports). Adding the LDADD+= -lc repairs the
> > existing binaries that were linked with the old gcc specs and
> > libc_r. I do not envy recompiling my handful of threaded apps. Not
> > all are from ports.
>
> OK, I misunderstood the goal when I replied before. I can see that it
> would be helpful to have libc_r depend explicitly on libc in order to
> make existing binaries work again.
You are supposed to be able to just link libc_r against libc, and
ELF is supposed to support this, so that everything "just works".
It was one of my concerns about the weak symbol reshuffle that,
if I have a libc_r that's linked against libc (so that a program
linked against libc_r gets libc as well), then if you replace a
libc function, that the automatic linkage "does the right thing",
and uses your function, when calling from libc_r, and not the libc
function.
The problem with this is that the system calls aren't in the
implementation space, per se, any more, so it'd be very hard to
wrap them again, transparently to the libc_r that has to call
the real system calls from the libc to implement threaded calls.
There are really two problems on top of this, then:
1) It seems to me that, in static linking, archives are no
longer really treated as archives, so that object code
is only pulled in, if referenced; this seems related to
#2, which is:
2) In linking, at lik time, the linker should act as if it
were going to be loaded with RTLD_NOD, instead of RTLD_LAZY,
even though in parctice, RTLD_LAZY will be the preferred
(default) method of operation. Archie Cobbs had a nice
problem with Kaffe and JNI, having to do with the fact that
ELF second order dependencies were not flagged as failing.
The easiest way to see #2 is to build two shared libraries, foo and
fee, and have like-named functions in each:
fee()
{
foo();
}
foo()
{
write( 1, "boom!\n", 6)
}
And link your program shared, and dlopen() fee, call fee, and watch
foo not be there and your program explode.
You can also do this with a shared link, going 3 deep, but the
cause is less obvious, being in the bowels of ld.so.
I spent several days going after a fix for this, but making it do
correct symbol accounting turned into a nightmare really quickly.
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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101300109.SAA11860>