With the exception of those ELF headers of our own we explicitly use, we're still using regular system headers on the build machine when doing a native build (on purpose), so it's still possible we could miss bits.  Though admittedly not these bits any longer.
I can remove the NATIVE_BUILD conditions we currently use, I believe, but I don't think we can stop passing the condition.

I wasn't suggesting we stop passing the condition. I hadn't realized that this was because of the system headers. So I think it's actually all fine.

It's all a stew.  I think I tried to be consistent with the file I was in, but I can do a second pass.

You're right.  I'd moved chckmsg too at one point, and forgot to undo this bit of that change

That's a good point, how do you envision that working?  Do we do it in cw, or do we have make pass it --linker, or?

I think I would probably have that bit there basically say something like:

if (getenv("LD_ALTEXEC") == NULL || == "") {
        set LD_ALTXEC from --linker
}

It seems weird for cw to ignore --linker, but it seems weird for Makefile.master to interpret LD_ALTEXEC, too.

Ugh.

Is expecting people who wish to use a different link-editor to override the variable to make a bad answer?

That is, to set LD in their build.
(I will check that this works properly, if it's an acceptible answer)

I don't like the surprise of LD_ALTEXEC being ignored, but I think that comes up rarely in testing this kind of thing and that one'd be able to just set the --linker argument in the makefile. So I guess that's fine.

Makes sense, and I guess what you describe is pretty much equivalent to what's expected.

You've marked this as an issue, is that "an interesting approach" in the same sense as "interesting times" and you'd prefer -include?

Sorry, that was erroneously marked as an issue. I think what's there now is reasonable.