From owner-freebsd-arch Mon Jan 29 17:10: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id A84A237B698 for ; Mon, 29 Jan 2001 17:09:42 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id SAA27242; Mon, 29 Jan 2001 18:04:59 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp05.primenet.com, id smtpdAAAFqaqk1; Mon Jan 29 18:04:52 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id SAA11860; Mon, 29 Jan 2001 18:09:23 -0700 (MST) From: Terry Lambert Message-Id: <200101300109.SAA11860@usr07.primenet.com> Subject: Re: libc_r badness To: arch@FreeBSD.ORG Date: Tue, 30 Jan 2001 01:09:23 +0000 (GMT) Cc: peter@netplex.com.au In-Reply-To: <200101291834.f0TIYL957823@vashon.polstra.com> from "John Polstra" at Jan 29, 2001 10:34:21 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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