From owner-freebsd-arch Thu Feb 15 19:47:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 48D1537B491 for ; Thu, 15 Feb 2001 19:47:23 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1G3klk48574; Fri, 16 Feb 2001 03:46:47 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f1G3lmw10596; Fri, 16 Feb 2001 03:47:49 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Warner Losh Cc: Brian Somers , arch@freebsd.org, brian@Awfulhak.org Subject: Re: The whole libc thing. In-Reply-To: Message from Warner Losh of "Thu, 15 Feb 2001 20:17:51 MST." <200102160317.f1G3HqE26659@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 03:47:48 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 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