From owner-freebsd-arch Tue Jan 30 0: 4:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 2D07137B503 for ; Tue, 30 Jan 2001 00:04:39 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0U84b462385; Tue, 30 Jan 2001 00:04:37 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101300804.f0U84b462385@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: libc_r badness In-Reply-To: Date: Tue, 30 Jan 2001 00:04:37 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > On Mon, 29 Jan 2001, Peter Wemm wrote: > > John Polstra wrote: > > > Have you actually used this much, i.e., having two different libc.so.* > > > versions loaded into the same program image? I am not sure that it > > > won't work, but it gives me mild heart palpitations to think about it. > > > > Likewise, it scares the hell out of me too. Just try mixing up malloc() > > from one libc with free() from another and see how far one gets.. > > > > Most of our troubles come from different dependencies of (custom) libperl > > and zillions of shared objects. I have seen a bunch of places where progra ms > > have ended up with libc.so.3 and libc.so.4 and it wasn't pretty. I believe > > it pretty much worked but that was more due to luck than anything because > > libc.so.3 we mostly used custom C++ libraries that used libc for little mor e > > than syscall stubs. > > In the past, libc_r.so versions have moved in lock step with libc, so > even if we did have libc_r depend on libc (assuming it could be), there > wouldn't be a problem. Now that applications can be linked with both > libc_r and libc, the libc_r version number does not have to be bumped > when libc is. If libc_r depends on libc, then the next time you bump > the libc version and rebuild world, you'll end up with this problem. > I suppose you could continue bumping version numbers in lock step, but > why if there is no reason to? No, if we bumped libc.so.5 -> libc.so.6, then the -lc dependency in libc_r.so.5 would change to libc.so.6 in the same buildworld. There is no need or value in having the versions in locked together. We could still freely bump libc.so and/or libc_r.so. However, it gets interesting in this scenario: cc -o app -l libc_r.so.5 -l libc.so.6 suppose we make a change to sigaction to change the size of signal sets and we introduce a new syscall number. bump libc's version buildworld libc_r.so.5 now depends on libc.so.7. (and suppose it makes internal calls ti sigaction, but *suppose* that libc_r didn't have any sigset exposure) ./app - which depends on libc_r.so.5 and libc.so.6. libc_r.so.5 will also pull in a copy of libc.so.7 into the namespace tree and you have two libc's loaded - but not level in the namespace. "./app" will make it's sigaction calls with the old sigset which will resolve to libc.so.6 using the old compatability syscall. libc_r.so.5 will make its internal sigaction calls with the new sigset and resolve to the new sigaction in libc.so.7 and will use the new syscall number with them. This is a contrived example, because sigset changes would almost certainly affect libc_r as well and would require a bump there too. But the example does show what can be done. I get headaches thinking about this stuff. For example, which malloc() and stdio etc would get used? Would libc_r use the new one but the app use the old one? Ouch. :-] Hmm.. if we did this, then perhaps we'd better keep them in lockstep.. ie: if libc is bumped, also bump libc_r (no need for the other way around though). That would avoid the two different libc's being loaded at the same time. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message