Date: Tue, 20 Feb 2001 21:03:31 +1000 From: Stephen McKay <mckay@thehub.com.au> To: Warner Losh <imp@harmony.village.org> Cc: Stephen McKay <mckay@freebsd.org>, arch@freebsd.org Subject: Re: The whole libc thing. Message-ID: <200102201103.f1KB3VC19818@dungeon.home> In-Reply-To: <200102191734.f1JHYQW61198@harmony.village.org> from Warner Losh at "Mon, 19 Feb 2001 10:34:26 -0700" References: <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
On Monday, 19th February 2001, Warner Losh wrote: >In message <200102191217.f1JCHno13825@dungeon.home> Stephen McKay writes: >: >Case 3. I've installed a port that installs libfred.so.3 from 4.2 >: >release. It contains __sF references. I have a binary (say barney) >: >that links libfred.so.3 and libc.so.4. Things work now. I rebuild >: >the world. Things still work because neither of the above has >: >changed. Now let's say I want to build wilma that depends on libfred. >: >When wilma is built, it will fail to run because it links against >: >libfred.so.3 and libc.so.5.20010220. This libc doesn't have __sF, so >: >it will fail at link time or run time. This is easy to fix. Just >: >rebuild the port tht produced libfred.so.3. A new libfred.so.3 is >: >installed. wilma will now run (maybe after being rebuilt). barney >: >will also still run because it gets all the symbols it needs >: >(including the new libfred.so.3). >: >: Doesn't barney die due to unresolved references to __stdout (etc) from >: the recompiled libfred.so.3? It only has the old libc.so.4 to help it. >: Or are you proposing to regenerate all libc.so.* back to the ELF >: transition? I am still confused, and still concerned, and still >: think a global major version bump is unavoidable. > >I am saying that we regenerate libc.so.[34]. barney then wouldn't die >from the missing symbol and life would be good, assuming that no >macros used _up, which I'm nearly positive none do. 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. >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). 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. >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. 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. Lastly, I'm happy that urgent commits have slowed, and we can work this out at a more civilized pace. Stephen. 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?200102201103.f1KB3VC19818>