[Noted that you don't like being cc:'d, David. On the other hand,
I like to be kept in the cc: list.]
On Tuesday, 26th December 2000, "David O'Brien" wrote:
>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.
Not really. If I generate an a.out binary right now, it can't suffer
from this problem, even though it uses ld.so when it runs. Only a
certain set of old a.out binaries are affected.
>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.
We almost completely agree, but...
The only a.out binaries with problems come from that 2.2/2.1 era. To
support them we need an ld.so from *after* that era. I can't see how you
get around this. That working ld.so was in 3.0 and was certainly no
generated on a 2.2.x host. I think your restriction on compat contents
is a useful guideline, but to be broken when necessary.
>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.
I'll build one if I have to. I'm trying to avoid unnecessary work, since
I expect there are few others bothered enough to fix this problem.
>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.
Could very well be me. But I would be patching the old location, surely?
>> 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.
This is the fundamental point of this problem. The executable was built
on a 2.2.x or 2.1.x box and originally used libraries compiled then or
earlier. The whole problem is the fact that libraries were recompiled
later and did not change version numbers. There was no way to force
external parties to update version numbers, and folks round here didn't
feel like bumping all the FreeBSD library version numbers.
This is why I keep the words "executable" and "library" separate. The
library is newer than the executable, and this causes the executable
to fail. This is the fact that I'm not at all sure that you understand.
>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.
We can only install one ld.so. It has to cover all bases. Are you
suggesting that each compat2x dist install a different ld.so? This
is consistent with your claim that "compat2x bits come from 2.x", but
not very useful in practice. Should I assume you meant to delete
ld.so from all but one compatxx dist?
>> 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''.
What I was going on about here is that important changes occurred to
libraries without a version bump, and one such library was libc. It
is making my attempt to describe the boundary of the problem very
difficult. I can't predict what happens when you run an old a.out
binary linked against the "version" of version 3.1 of libc that didn't
have __error in it. This sort of confusion is what the versioning
system was supposed to prevent.
>> 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.
And built from source or just copied around? I thought that was still
in doubt. No matter, since I expect neither of us would be satisfied by
copying one of these ld.so variants.
>> 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.
Actually, I'd like you to go one more round in this if you can stand it.
I'm not interested in just wearing you down until you give in. I really
want you to understand this problem in detail because I don't think I got
through to many people the first time. Since you are so involved in the
build tool chain, I want to be certain you know everything that went
wrong last time round so we don't have a repeat. I'll risk being
tediously pedantic to achieve this. :-)
And finally, to action: Unless you object, I'll try setting up a 2.2.8-stable
box and have a go at making a working ld.so. If this is too much pain,
I'll commit a magic binary that the 4.2 pixies have given me and take all
the heat if there are problems.
I'm undecided whether to update all copies of ld.so found in compat dists,
or just delete all but the last copy. You were going to delete them, right?
Stephen.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
