Date: Wed, 21 Feb 2001 22:25:09 -0700 From: Warner Losh <imp@harmony.village.org> To: Stephen McKay <mckay@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: The whole libc thing. Message-ID: <200102220525.f1M5P9W02890@harmony.village.org> In-Reply-To: Your message of "Tue, 20 Feb 2001 21:03:31 %2B1000." <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>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102220525.f1M5P9W02890>