@Ericson2314 @bgamari Is this the right thing to do here? I'm not quite sure with respect to cross-compilers what set they should be coming from.

Oh, right, I think, though I'm not very certain either. Plain gcc7 would be compiler runnable on the host.

BTW, the lines you're fixing are reverted on the gcc-7 branch, and I expect it will be soon merged to master.

Perhaps "overrideCC" (or a new variant) should check the platform of the compiler?

As-is I think more or less all of its usage will result in this sort of breakage, and generally not be very clear why :).

If nothing else, I think it'd make sense to replace all uses of "overrideCC X Y" with "overrideCC X buildPackages.Y"; although perhaps there are a few exceptions. Does that sound good? I can put together a PR doing so if that'd be useful.

EDIT: I had overrideCC argument order wrong :)

Hmm, I'll admit I'm not certain; it looks plausible but I think @Ericson2314 is probably best equipped to answer this.

Oh, wait buildPackages is wrong in most circumstances anyway, nevermind. Want nativeBuildInputs but no package set for that :(.

Hi I'm back. Uh oh, I think I need to write more docs if nobody knows the answer :D. This is exactly correct, buildPackages does correspond to nativeBuildInputs, everything is good.

Only issue is buildPackages.stdenv.cc might also be in use, but whatever. We don't care if temporary tools are made with that.

Also, I should mention that I have noticed that the gcc7 build segmentation faults when cross-compiled for ARMv7.

That's sad, as gcc7 is now the default on master.

Time to fix things, then! 😁

@bgamari How do you reproduce this? Building a cross compiler or cross compiling GCC?

I've successfully cross compiled a kernel for armv7l after the GCC 7 merge earlier today.

Cross-compiling gcc, i.e. compiler runnable on armv7, if I understand him correctly.