Date: Fri, 16 Feb 2001 03:47:48 +0000 From: Brian Somers <brian@Awfulhak.org> To: Warner Losh <imp@village.org> Cc: Brian Somers <brian@Awfulhak.org>, arch@freebsd.org, brian@Awfulhak.org Subject: Re: The whole libc thing. Message-ID: <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org> In-Reply-To: Message from Warner Losh <imp@village.org> of "Thu, 15 Feb 2001 20:17:51 MST." <200102160317.f1G3HqE26659@billy-club.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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....
> 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].
> The solution to all this mess is to sit tight. I know people hate
> doing that, but those people will have to cope for a while.
>
> Here's what I propose after my patches go into the tree:
> 1) We introduce some assembler or other magic that will alias
> __stdin to __sF[0], __stdout to __sF[1], etc being
> careful to preserve the size of FILE, and the __sF array.
> 2) We introduce this assembler to all ELF RELENG branches.
> This is just RELENG_3 and RELENG_4 and current, so it isn't
> as bad as it sounds.
> 3) We wait a while.
Ok, so we've now got a bunch of machines out there that have mostly
got binaries that can survive into the future.
> 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).
> The reason we wait a while is to give people a chance to upgrade their
> libc.so.3 and libc.so.4 libraries. If they do this, or if we have the
> "fixed" libraries in compat, then the old binaries will just continue
> to work.
>
> Why you ask? Well, new libraries will have __std* in them. What is
> breaking things right now is that the old binaries were linking
> against libc.so.OLD which doesn't have the __std* symbols. If we add
> them to the old libraries as aliases, things will work as before.
> Maybe even "better" because the new shared libraries won't have __sF
> encoded into them. The old binaries will still have __sF encoded into
> them, but that's OK because they will be using a library that matches.
>
> The only wrinkle in all of this is old libraries and fresh builds
> after libc's version is bumped. They will break because they will
> have __sF in them. We've had this sort of problem before, and can
> tell people in those cases they will have to rebuild the libraries.
> When they rebuild the libraries, they will be abled to be linked with
> old and new libc and they won't even have to recompile their old
> binaries, just the old libraries.
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).
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 :-(
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''.
> Warner
[__std* setup examples elided]
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
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?200102160347.f1G3lmw10596>