tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: GNU tools netbsd vs netbsdelf

I've now reached out the the Binutils and GCC lists in / Fingers crossed!

On Fri, Jun 11, 2021, at 7:01 PM, David Holland wrote:
NetBSD doesn't support a.out any more either; while some a.out bits
hang around in places (mostly to interface with archaic firmware), if
you managed to build the system as a.out and it worked it would only
be by accident.

Thanks for confirming this (I should have asked). That's good to know and strengthened the case.

If you dig around in the GNU toolchain configury (I just had the
misfortune to be doing this last week) you'll find that the NetBSD
configs are the outlier.

Indeed they are.

You'll also find that the upstream configs are incomplete/outdated
with respect to the ones in the NetBSD tree (because we tend not to do
a very good job of coordinating with upstream) so I have some doubts
about whether they can in general be expected to work without
editorial intervention.

Good to know. I guess if anything that helps me? An expectation of some downstream divergence means I wouldn't have to

Anyway, ISTM that it's foolish for the upstream configury to pretend
that NetBSD a.out is still a valid target; there should in general be
one NetBSD target per machine, it should be accessible as "netbsd",
and be ELF. Should we ever move on to some other format (not a.out,
a.out is not coming back) we can add more configs then, and, with
luck, manipulate the default in a more sensible manner.

If you ask me the default in the upstream tools should have changed
when the default changed in the system, which was long ago.

I agree with all of that! (And per my original first suggestion perhaps that would be done with an additional component anyways.)

Anyway, a much less theoretical problem is: if you are closely enough
tied to the GNU triple system that a minor inconsistency like this
causes trouble, where will you be the next time they decide to change
it around upstream as a political football?

Well remember, per what Alyssa said more clearly than I, that we were never blocked by this. Our parser/printer in has special cases for this and other things at the moment. I just want to keep that complexity to a minimum.

If you are curious, know that this isn't my first rodeo of this sort hah --- I have already rewritten most of GNU's config.sub: . It seems these configs aren't organized that much --- these issues arise because no one bothers to systematize them, not because of excessive meddling upstream. The fact that I am proposing a change that could have been made decades ago, as you say, makes me think these inconsistencies pop up quite slowly, so it shouldn't be too hard to keep up.


Home | Main Index | Thread Index | Old Index