From owner-freebsd-arch Wed Feb 21 21:25:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6918737B401; Wed, 21 Feb 2001 21:25:10 -0800 (PST) (envelope-from imp@harmony.village.org) 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 f1M5P9W02890; Wed, 21 Feb 2001 22:25:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102220525.f1M5P9W02890@harmony.village.org> Subject: Re: The whole libc thing. To: Stephen McKay , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Feb 2001 21:03:31 +1000." <200102201103.f1KB3VC19818@dungeon.home> References: <200102201103.f1KB3VC19818@dungeon.home> <200102191217.f1JCHno13825@dungeon.home> <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> <200102170638.f1H6ckW84622@harmony.village.org> <200102191734.f1JHYQW61198@harmony.village.org> Date: Wed, 21 Feb 2001 22:25:09 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ I don't think I've replied to this [[ In message <200102201103.f1KB3VC19818@dungeon.home> Stephen McKay writes: : There have never been macros that use _up, and I can't see any reason : for nasty FILE-grovelling programs to use _up. Should be safe. Good. That was my reading as well. : >We've added : >symbols like this in the past for various reasons, but maybe never so : >late in the 3.x branch. We also have the technology to regenerate the : >libc.so.[34] in place if we needed to w/o recompiling, but polishing : >it for the great masses will take some time. : : Ah, I see. You fix the problem by fixing all copies of libc, which in : this case is really just two versions. This has two interesting results: : people who don't upgrade anything at all can enjoy their ignorance in : peace, and those who upgrade something causing it to break, can be told : to install a compatible hacked libc, which fixes their current problem : and all future problems (to do with FILE). Right. : But that only gets you through part one. When part two (FILE becomes : radically incompatible) arrives, what then? Old binaries and/or : libraries will always want to see __sF, and will pass around pointers : into __sF. Will libc forever after translate &__sF[1] to __stdout? : How could it hope to support old binaries that fiddle with the insides : of FILE? It can't. I predict that these binaries will be orphaned. FILE won't become radically incompatible without a major version bump of everything. Libc will, for the libc.so.5 series, define it, but not past that. FILE has to have a stable first 88 bytes, or we have to bump all shared major version numbers. It can grow, once we take the 88 out of the __sF[] stuff. : >After talking with Peter on IRC extensively about this, I think that : >we need a bigger window where we generate __stdout before trying to : >take the plunge. There are still too many libraries that depend on : >__sF. : : Do I read this as "keep the hack in place long enough so that every : binary anyone cares about has been recompiled"? If so, I think this : is going the wrong way. If we are going for a global recompile, it : should be explicit, but not in a way that overwrites existing libraries. I think we disagree on this. In the end you may be right, but the prospect of forcing a major bump on all the libraries in ports was beyond my idea of a reasonable change. : Oh, and earlier I forgot to highlight your comment: "This is easy to fix. : Just rebuild the port that produced libfred.so.3." This implies that : recompiling a lot of stuff is central to your plans. I claim that we : can make this recompiling explicit and safe to all past and future : binaries by equating this recompile with a major version bump. Everywhere. This may be true. The other reason that I worried about bumping all the major numbers in all the ports is the effect on the current/stable split. We'd need different versions for stable and current on all the ports, and all the depends and such. i don't see a good way of doing that. We encode major numbers all over the place in /usr/ports/*/*/Makefile, but for the major that we generate, as well as the LIBDEPENDS. It would be a nightmare to support two versions in all of them. : Lastly, I'm happy that urgent commits have slowed, and we can work this : out at a more civilized pace. Yes. I wanted to get this over, but you are right that we need to think about this more. I fear that we'll end up with the least evil of many evil choices. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message