Date: Tue, 30 Jan 2001 08:25:40 -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.1010130081050.25016A-100000@pcnet1.pcnet.com> In-Reply-To: <200101300804.f0U84b462385@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Jan 2001, Peter Wemm wrote: > 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. Right, but an older application will pull in libc.so.5 and libc_r.so.5, but libc_r.so.5 will (now, after buildworld) also pull in libc.so.6. > 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. Right, this is exactly what I was trying to say above. > 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. :-] And which locks (spinlocks, mutexes) in libc.so.5 and libc.so.6 will get used? > 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. In a perfect world, we would have made the libc/libc_r change the same day as the library versions were bumped and we'd have no problem. I see no reason to have libc_r.so depend on libc.so other than to have threaded apps that were built in the last 2 months continue to work without being recompiled. -- 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.1010130081050.25016A-100000>