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