Re: GNU tools netbsd vs netbsdelf

["John Ericson" <list%johnericson.me@localhost>]

I've now reached out the the Binutils and GCC lists in https://sourceware.org/pipermail/binutils/2021-June/116923.html / https://gcc.gnu.org/pipermail/gcc/2021-June/236406.html. 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 https://github.com/NixOS/nixpkgs/blob/master/lib/systems/parse.nix 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: https://git.savannah.gnu.org/cgit/config.git/log/?qt=author&q=John+Ericson . 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.

John