Re: GNU tools netbsd vs netbsdelf

On Thu, Jun 10, 2021 at 11:10:18PM +0000, Alyssa Ross wrote:
 > I'm happy enough with what we have now, which is a special case that
 > says "if the user asks for a NetBSD build, and it's for an
 > architecture where binutils would default to a.out, override it to
 > force it to ELF".  The only reason we do that in the first place is
 > that binutils doesn't support NetBSD a.out any more.

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.

 > I tried building an upstream GNU cross toolchain with
 > --host=i686-unknown-netbsd, and I got an error saying that the
 > platform was unsupported.  That surprised me, so I asked a NetBSD
 > developer I know for help, and was told that i*86-unknown-netbsd means
 > a.out to the GNU build system by default, and that the scary message
 > from binutils just meant it didn't support NetBSD a.out, and if I
 > changed it to "netbsdelf" it would be fine.

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.

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.

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.

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?

-- 
David A. Holland
[email protected]