From owner-freebsd-arch Thu Feb 15 19:59:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3E8A737B503 for ; Thu, 15 Feb 2001 19:59:41 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1G3wrW56778; Thu, 15 Feb 2001 20:58:53 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102160358.f1G3wrW56778@harmony.village.org> To: Brian Somers Subject: Re: The whole libc thing. Cc: arch@freebsd.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> Date: Thu, 15 Feb 2001 20:58:53 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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