Re: Fwd: GNU tools netbsd vs netbsdelf

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

On Fri, Jun 11, 2021, at 9:35 AM, nia wrote:

Only older platforms that were previously a.out.

The most popular NetBSD platforms have always been ELF,

so are simply "netbsd".

Yes, we encountered this doing an x86_32 build.

> My first suggestion is that these GNU tools should support <CPU>-netbsd-elf and <CPU>-netbsd-aout as alternative ways of disambiguating. Putting it in an additional "abi" component of the config (this is the 4th component with a vendor (including "pc" or "unknown" in the second position) is something we already support for e.g. bare metal programing that nonetheless use ELF (as supported by the bootloader or whatever). This has the advantage of being a non-breaking change.

I don't see the reason for this change.

Only the kernel has to care about a.out still, the toolchain

no longer supports building a.out binaries.

The ABI component is used for other purposes on e.g. ARM,

so I don't think it would be non-breaking at all.

I didn't realize how dead a.out was already, I no agree.

> My second suggestion would just be to change the meaning of the ambiguous plain "netbsd" to mean ELF rather than a.out by default. NetBSD has, of course, supported ELF for many years now, and other OSes that switched to ELF have made the same change long ago

I agree that "netbsd" should mean ELF by default.

Great!

> so this would be hopefully be only a tiny breakage, and one with precedent. See also this comment in GNU config that even anticipates this change [gnu-config-comment].

I would hope that it if you suspect that it would cause breakage

you've evaluated exactly how much breakage it would cause, where,

and how it can be fixed.

Running a pkgsrc bulk build to prove your change doesn't break

anything would be a great gesture to prove it's the right

change.  I'd like to avoid any pain on our side.

Since a.out is barely supported in binutils these days, as I've learned, I actually think now this it will be harder to find a situation where this causes breakage.

On Fri, Jun 11, 2021, at 10:10 AM, Martin Husemann wrote:

On Fri, Jun 11, 2021 at 01:35:13PM +0000, nia wrote:

> I don't see the reason for this change.

I don't see a reason for any change.

E.g. in my current $TOOLDIR/bin I see:

arm--netbsdelf-gcc

i486--netbsdelf-gcc

m68010--netbsdelf-gcc

m68k--netbsdelf-gcc

shle--netbsdelf-gcc

sparc--netbsdelf-gcc

vax--netbsdelf-gcc

Is any of those targets actually a reasonable target for Nixpkgs?

If so, I guess only the i486--netbsdelf-gcc would be of interest, and

knowing that it is exactly this (and we internally call it i386, and

everyone uses x86_64/amd64 anyway) certainly is prerequisite knowledge

and totaly unrelated to the historical nit of netbsd vs netbsdelf.

I guess I am missing something.

Martin

We encountered this doing x86_32 builds, but we have also done arm builds for old phones and what not. We also support building toolchains for bare metal platforms etc. where no normal packages would run, for sake of people working on embedded systems with Nix.

Moreover, while we certainly don't test every single combination, I suppose I at least aspire so that one could *attempt* building a toolchain for anything the upstream tools support. Nixpkgs isn't really in the business of imposing artificial limitations; our only constraint the need to limit ourselves with platform-specific code that would piss off "regular" contributors who don't about these thing if it grew unchecked.

John