Date: Mon, 29 Jan 2001 22:34:37 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Peter Wemm <peter@netplex.com.au> Cc: arch@FreeBSD.ORG Subject: Re: libc_r badness Message-ID: <Pine.SUN.3.91.1010129221952.14131A-100000@pcnet1.pcnet.com> In-Reply-To: <200101300253.f0U2ro459515@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1010129221952.14131A-100000>