Date: Thu, 15 Feb 2001 20:58:53 -0700 From: Warner Losh <imp@harmony.village.org> To: Brian Somers <brian@Awfulhak.org> Cc: arch@freebsd.org Subject: Re: The whole libc thing. Message-ID: <200102160358.f1G3wrW56778@harmony.village.org> In-Reply-To: Your message of "Fri, 16 Feb 2001 03:47:48 GMT." <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org> References: <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org> Brian Somers writes:
: > That's right. That's the problem. Actually, none of them are mucking
: > with the internals of libc. They just know that __sF[0] is stdin,
: > __sF[1] is stdout, etc. They know the size of FILE. That's bad.
: [.....]
: > Programs that play with the internals of stdio are few and far between
: > these days. Too many different ones :-)
:
: Programs use macros, but on a binary level they're still playing with
: the internals....
Yes. I understand that. Which is why FILE is still in the same order
and can only ever grow in size. Brian Feldman was smart to pick _up.
: > The problems come up when we're trying to introduce new symbols. If
: > we do it smartly, and give users a transition time to rebuild (say 3-6
: > months), then we'll be be able to make this transition mostly
: > seamless.
:
: Ok, that I understand. You're aiming for an intermediate period
: where you make binaries ``better able to cope with things being
: changed''. This is the idea behind using __stdxxx rather than
: sF[0-2].
Yes. That's right.
: Ok, so we've now got a bunch of machines out there that have mostly
: got binaries that can survive into the future.
Yes. And if they don't, they can easily be upgraded with a simple cp
or pkg_install.
: > 4) We bump libc.so.5 to libc.so.5.20010501 or something like
: > that. At this stage, we make __std* ala peter's changes
: > and start generating binaries with __std* references.
: > These will work with the old and the new libc, since
: > the size of __sF isn't encoded into the binary. This means
: > that old binaries with slightly fixed old libc will
: > continue to work.
:
: Right, but binaries from before your first commit (1 above) are
: potentially dead in the water - (yep, you already know this, but this
: is my concern -- see below).
I don't understand this, so I'll draw a timeline and see if you can
tell me what you are talking about:
libc.so.3 ----- libc.so.4 ---- libc.so.5 ---- Feb 10 --- Today --- tomorrow
1 2 3 4 5 6
The only area that I know that binaries programs will be busted is the
4 - 5 period. The rest should be good to go with this, assuming that
their libc can be updated with the latest cool bits.
: Ah, ok, so you have thought of that :-) That was my concern - that
: there are libraries running around that use __sF and don't have a
: NEEDED libc.so.something in them (I'm not sure if this is a linker
: bug - I'm assuming it is).
There's no library version info, iirc. Even if there is, FreeBSD has
the Highlander rule: There Can BE only One.
: I don't get the bit about the old binaries not needing to be rebuilt.
: Surely they're still going to have references to __sF sizes *AND*
: are potentially going to use one or more of these horrible libraries
: without the NEEDED libc.so.something that have now been rebuilt and
: are doiking about with the new-improved FILE. When the old app gets
: ldd involved, we end up with the old binary, the old libc and the new
: other-library-without-the-NEEDED-bit, which is going to fail to all
: link together at run time :-(
old binaries use old libc.so.[34] by definition. ELF doesn't let you
have two different libc's brought in.
: I must say, I've never understood why libraries end up with external
: references to other libraries, but no idea about the version numbers
: of those other libraries. This seems to be ``just wrong''.
:
It is ELF.
Warner
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?200102160358.f1G3wrW56778>