From owner-freebsd-arch Mon Jan 29 19:35:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6903537B400 for ; Mon, 29 Jan 2001 19:35:12 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA16084; Mon, 29 Jan 2001 22:34:37 -0500 (EST) Date: Mon, 29 Jan 2001 22:34:37 -0500 (EST) From: Daniel Eischen To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: libc_r badness In-Reply-To: <200101300253.f0U2ro459515@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 programs > 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 more > 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? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message