Date: Wed, 20 Dec 2000 23:15:55 +1000 From: Stephen McKay <mckay@thehub.com.au> To: obrien@freebsd.org Cc: "Donald J . Maddox" <dmaddox@sc.rr.com>, current@freebsd.org, mckay@thehub.com.au Subject: Re: Is compatibility for old aout binaries broken? Message-ID: <200012201315.eBKDFtB24592@dungeon.home> In-Reply-To: Message from "David O'Brien" <obrien@freebsd.org> of "Wed, 20 Dec 2000 01:42:59 PST." <20001220014259.G41741@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 20th December 2000, "David O'Brien" wrote: >On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote: >> This has been broken for new users for some time. :-( Those of us >> upgrading from source have been immune to this problem, because we >> retain the old a.out ld.so binary. >> >> >/usr/libexec/ld.so: Undefined symbol "___error" called from >> >sim:/usr/X11R6/lib /aout/libX11.so.6.1 at 0x20160644 >> >> When errno became a function that returns a pointer (previously it was >> a simple integer variable), recompiled libraries became incompatable with >> old binaries. So, I hacked the a.out loader (ld.so). The fix was in 3.0. >> Well, Nate called it a horrible hack, so maybe I should say "the hack was >> in 3.0". > >src/lib/libc/sys/__error.c suggests this was the case for 2.2.7+. No, you want rev 1.10 of sys/sys/errno.h. That was when it affected all a.out binaries. Until then it was just threaded binaries, a vanishingly small proportion. Rev 1.10 was in 3.0. Rev 1.5 was in the 2.2.x releases. >What is out of sync is the X11 a.out libs. They are probably built on a >2.2.7 or 2.2.8 box, thus they refer to `___error' vs. `errno'. These >libs are wrong for the SimCity binary. They are a.out yes, but not >proper for compat20 use. Since SimCity needs `libgcc.so.261', I'll >assume it was built that long ago. Correcting slightly for your slightly off assumption: The X11 libs were probably built on a 3.x box. Their problem is that being newer than libc.so.2.2 (or was it libc.so.3.0) they use ___error but libc does not supply it. My patches to rtld-aout (that first appeared in FreeBSD 3.0) supply ___error in this case. This is the only full fix for this situation. >The problem isn't as much ld.so, as it should match the libc.so, et.al. >you are using from the compat2[01] dist (needed to satisfy ``ldd >lib/SimCity/res/sim''). And `ld.so' and the shared libs would be >consistent on the system the a.out program was built on. There was an enormous thread in -current (I think) at the time (mid 1998). The end result was that the ld.so hack was the only solution other than mandating a major bump to every library in existence. Nobody liked either of those solutions :-) but I put the ld.so hack in and the problem disappeared. Emphasis again: the workaround ld.so was only found in 3.0 and onward, so just using a 2.2.x ld.so isn't enough. >What I would feel most comfortable with, is doing a MFC to RELENG_2_2 of >the rtld-aout changes since then, building a new `ld.so' and putting that >in the compat2? dists. Problem is I don't have access to a 2.2-STABLE >box. I have built a binary on 4.2-RELEASE. I think I prefer that because any security fixes in libc (or whatever) will be reflected in the resulting ld.so. In fact, I think we should build ld.so from source until such time as a.out building capability is removed (5.0 perhaps). On the other hand, merging back to 2.2.x and rebuilding should provide a working (and hack enabled) ld.so that has no more problems than the old binaries it is supporting. >> I poked about with my old FreeBSD CD collection and found that >> version 3.0 through 3.2 have a fully functioning (fully hack enabled) >> ld.so, but an older binary has been substituted in 3.3 and onward, >> including 4.0 and 4.1, and most likely 4.2 also. > >Are you sure? src/lib/compat/compat2[012]/ld.so.gz.uu are all at >rev 1.1. So there has been no change to them over the lifetime of their >existence. All three are identical -- having the same MD5 checksum. >Well, looking at the release tags compat22/ld.so was in 3.2. >compat2[01]/ld.so was added for 3.3. This very fact is bothering me a lot. Get out your 3.2 disks and verify that they do not match these uuencoded binaries. Check the 3.0 and 3.1 disk 2 (live file system) and see that they don't match them either. >> I can only guess that some anonymous release engineer (nobody we know :-) >> picked the wrong CD at some point to get the master copy of ld.so once >> it stopped compiling. (Or at least stopped being easily compiled.) > >Not quite. I seem to remember that JKH was makeing a tarball of a.out >libs from what ever was on his box at the time (thus probably the last >a.out ld.so just before E-day on 3-CURRENT). Something like this must have happened up to and including the 3.2 release. >When I committed the >compat2? bits, I took ld.so from a 2.2.x release as this is the compat2? >dist, not compat3.aout dist. Which is what you're suggesting should have >been done. You missed the fact that fixes were added to ld.so after those releases even though the purpose of ld.so is to run binaries that date from those releases. The existence of later, recompiled libraries requires this. Stephen. PS In just a few hours, I'll be out of the picture for 4 or 5 days. I hope I've given you a complete understanding of the situation in the event that I don't get to commit anything. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012201315.eBKDFtB24592>