Re: GNU tools netbsd vs netbsdelf

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