Are you sure this has any effect? nativeBuildInputs should only have a difference when cross compiling.

@chpatrick the runtime/buildtime distinction has to do with where the code is supposed to be executed. If it is build-time only it must be compatible with the build machine; if it is run-time it must be compatible with the host machine (using gnu terminology). If build=host, then buildInputs=nativeBuildInputs.

Absent enforcement, it makes no difference except for cross compilation. I agree with putting things in the correct variable, however, I was just elaborating on what I assumed @dezgeg was referring to.

If build=host, then buildInputs=nativeBuildInputs.

Absent enforcement, it makes no difference except for cross compilation.

If you're building for the exact same architecture but a different physical machine, I don't believe that's considered cross compilation. However, buildInputs end up in your run-time closure and nativeBuildInputs don't, so I don't think it's correct to say that it's the same.

This means that in the the most common case where you aren't cross compiling, buildInputs and nativeBuildInputs are somewhat misleading names because the actual difference is whether they're build-time or run-time dependencies. This is why I think they're confusingly named and lead to unnecessary dependencies.

If you're building for the exact same architecture but a different physical machine, I don't believe that's considered cross compilation.

That's not what I'm saying ... In that case build=host, i.e. non-cross.

Consider

{ stdenv, bc }:

stdenv.mkDerivation rec {
  name = "native-capture";
  nativeBuildInputs = [ bc ];
  buildCommand = ''
     echo $nativeBuildInputs >$out
  '';
}

The closure of the result will contain bc &c. This is what I mean by absence of enforcement. The builder is free to capture references to "native" build inputs, so there is no distinction between buildInputs and nativeBuildInputs in that regard.

Anyway, more to the point, cc @mdaiter to review the change itself.

This will most probably not change anything as @joachifm and @dezgeg have tried to explain, probably the resulting executable has a reference to gcc itself. That might possibly be needed, possibly only in a string. You might want to look at removeReferencesTo for that. I would oppose merging this, unless you can show us dependency graphs that show that this really changes the runtime dependencies.