On Wed, Dec 27, 2000 at 02:01:24AM +1000, Stephen McKay wrote:
> I'll try to summarise the position so far:
>
> 1) Legacy a.out executable support is broken for a subset (size unknown)
> of such executables.
Define "legacy". I have been speaking specifically about FreeBSD 2.2
support. That just happens to a.out based.
You seem to mean it to be any a.out binary.
> 4) We can generate a working binary on 4.x or on 2.2.8-stable (after some
> fixing).
>From my standpoint only bits generated on a 2.2.x host can go into the
compat22 distribution. When compat1x was created (being the first it
gets to imply the intention of the compat dists) it gave the ability to
run FreeBSD 1.x binaries; not 2.0 a.out ones, not any binary after the
last 1.x release. Thus why I claim compat22 is *not* about being an
a.out compat dist, but one to properly run 2.2.x binaries on a later
version of FreeBSD. If 3.0 had been a.out based, there still would be a
compat22 dist.
Thus someone that still has access to a 2.2.8-stable box needs to merge
the changes in src/libexec/rtld-aout (in -current) to
src/gnu/usr.bin/ld{,/rtld} and build a new binary for inclusion in the
compat22 dist.
Note, when the bits were CVS repo copied into rtld-aout, all the tags
were stripped. I spent the time to add them all back to make the merge
easier for someone. Whoever does this should please CVSup before
starting.
> 5) We can generate ld.so anew each release, or generate it (or find it)
> once and commit a binary.
>
> I don't think there's any doubt about point 1. All a.out executables that
> use libc.so.2.2 and another recompiled library will fail because of a
> missing routine (__error) required by the recompiled library and not
> supplied by libc or by executable or by the existing ld.so.
Agreed, but "and another recompiled library", means this a.out
executable was not built on a 2.2.x host. Otherwise there would be no
way to have this inconsistency.
Actually one problem is I put the 2.2.8 ld.so in the compat2[01] dist.
That was wrong of me. I can correct that. SimCity (the binary used as
an example) required me to install the comapt20 and compat21 dists. The
other problem is we don't have a compat2[01] XFree86 libs dist. We only
have an a.out one that is intended to cover all a.out binaries, and it
doesn't correctly.
> 2.2.5 had libc 3.0 (without __error) and 2.2.7 had libc 3.1 (with
> __error) but the cvs logs say that 2.2.6 should have had a different
> libc 3.1 (without __error). So, the exact "version" of version 3.1 of
> libc could be important. Yuck.
The compat22 dist used the 2.2.8 bits, so I don't see how it wasn't the
``exact "version" of version 3.1 of libc''.
> We don't normally ignore things we can fix, so point 2 is resolved in
> favour of fixing this, right?
Of course. :-)
> We need to build a new binary since we (collectively) have forgotten
> where the working 3.0 through 3.2 binaries came from. :-(
It haven't forgotten, I told you. They came from JKH's workstation's
/usr/lib/aout.
> It seems feasable to generate a new binary on a recent or an old patched
> FreeBSD version. The question is which is better. I think the newer
> the better.
I maintain the only correct way is to build the new binary on a 2.2.8
box. I've experienced enough how seemingly little changes in the low
level binary bits can have bad effects. I'm still working on making
everyone happy with the libgcc and shared linking changes that went in
before 4.2.
> Otherwise, who is going to build the 2.2.8-stable box to make this one
> binary? I've already built a binary on 4.2-release that works.
Fine. I'm tired of discussing this. I have tried to make clear there are
peril in mixing of different binary bits. Do what you like, just please
make sure I'm not associated with committing this binary and thus I don't
get any problem reports on the topic.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
