Date: Wed, 20 Dec 2000 10:14:09 -0800 From: "David O'Brien" <obrien@freebsd.org> To: Stephen McKay <mckay@thehub.com.au> Cc: current@freebsd.org Subject: Re: Is compatibility for old aout binaries broken? Message-ID: <20001220101409.B8849@dragon.nuxi.com> In-Reply-To: <200012201315.eBKDFtB24592@dungeon.home>; from mckay@thehub.com.au on Wed, Dec 20, 2000 at 11:15:55PM %2B1000 References: <obrien@freebsd.org> <200012201315.eBKDFtB24592@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 20, 2000 at 11:15:55PM +1000, Stephen McKay wrote:
> 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.
Why is not changing the XFree86-aoutlibs port to offer libs built on
2.2.x not the right fix?
> 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.
I am very uncomfortable putting in a ld.so built on 3.0 into the compat2?
dists. I'm painfully aware of all the un-thought of issues that can come
up when changing dynamic linking methods, etc.. just look at the two
opposing threads in the past month about how to handle libcc and dynamic
[and threaded] libs and binaries.
> In fact, I think we should build ld.so from source until such time as
> a.out building capability is removed (5.0 perhaps).
Fine BUT IT ISN'T compat2?. PLEASE think about the issues for a moment.
You are mixing bits that are not consistent. Maybe it fixes this one
case, but what about all the other cases. What we need to do is offer
a.out bits so users can duplicate the system the binary was built on.
4.2 a.out bits != 2.2.x a.out bits. There are two issues here -- binary
format (a.out vs. ELF), _and_ library versions.
> 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.
And is consistent with the binaries and libs of that release.
> >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'm sure they don't -- I just wrote above I didn't add ld.so to the
compat2? dists until 3.2 and 3.3. So of course the 3.0 and 3.1 a.out
bits are different.
> 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.
No, you're missing the fact that these are comat2? bits, not a.out bits.
If you want 3.x a.out bits then a compat3x.aout dist should be created.
--
-- David (obrien@FreeBSD.org)
GNU is Not Unix / Linux Is Not UniX
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?20001220101409.B8849>