gcc-wrapper doesn't handle arguments specified in response files

[peti]

According to https://gcc.gnu.org/wiki/Response_Files, gcc reads for every argument of the form @path the file path and inserts its contents in the command-line array as if those flags had been specified directly. This mechanism is supposed to be used to work around system limitations with regard to command-line length.

The Haskell compiler GHC has picked up the habit of using those response files for all its linker arguments, and it's now broken on NixOS as a result, apparently because all kinds of "rpaths" are no longer provided correctly.

My theory is that before that patch, gcc-wrapper would catch the -L/path/... style arguments and handle them correctly, but now it no longer does, because those flags are hidden inside of a response file. Does that sound plausible?

Cc: @vcunat

[vcunat]

My guess is that something isn't quoted properly in the wrapper, as @ is certainly a bash-active character.

[vcunat]

So, the ghc issue was worked around but this issue itself probably lasts. (Correct me if I'm wrong.)

[peti]

Yes, I've patched ghc to avoid using response files. If it does, however, then the compiler won't work anymore, clearly because our wrapper doesn't cope with response files correctly. The symptom we observe is that glibc libraries like rt are linked without getting their "rpath" hard-coded. The resulting binaries will then fail at run-time.

[corngood]

I just ran into this with one of my own projects. It's trivial for me to reproduce:

test.rsp: test.cpp
test.cpp: int main() { return 0; }

$ g++ test.cpp
$ ./a.out
$ g++ @test.rsp
$ ./a.out
./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

In the second case the RPATH is missing as you described.

Before I get into fixing it, has anyone done any work on it? I'll probably just start with unpacking the response files into params in ld-wrapper.sh (then probably move it into utils) unless you have a better idea. I don't see anything in there that looks like it's meant to handle @.

[peti]

I am not aware of any attempts to fix this yet.

[peti]

I tried building ghc without the "no-response-file" patch in d41c660, and the build is still broken even after 1ad1edb: http://hydra.cryp.to/build/2053991/nixlog/2/raw. The error looks like some "-L" argument passed during the build isn't translated into an "rpath" linker argument to hard-code the path.

[corngood]

@peti It looks like arguments such as -optl-Wl,'$ORIGIN' are causing the problem. It must be evaluating the variable when the response file is read, because it's passing -opt-Wl,'' to the compiler.

I'll see what I can do in cc-wrapper.

Thanks

[corngood]

@peti. I think I have a fix for this. Could you take a look at #20561?

Is it possible to use hydra to check for regressions before merging?

[peti]

@corngood, Hydra is building the new code at http://hydra.nixos.org/jobset/nixpkgs/staging. Unfortunately, the staging branch appears to be in bad shape right now; there're plenty of errors that seem unrelated. 😞

[vcunat]

It seems almost all the failures is just a failing guile test on i686-linux which I can't reproduce locally (probably appears randomly).

[vcunat]

Hmm, merging master to staging turned out to be a huge rebuild in itself :-/ so I squeezed in a stdenv rebuild.

[peti]

I suppose we can close this issue? The ghc binaries on master seem to work fine now even when use of response files is enabled!

@corngood, @vcunat, do you happen to know whether all relevant fixes for gcc-wrapper have been ported to the release-16.09 branch?

[vcunat]

I can't say I know.

[corngood]

It's fixed in 175461e, which doesn't seem to be merged to 16.09.

[corngood]

If you do want to cherry-pick, you need 1ad1edb and 175461e, but it's probably not worth doing unless you want the ghc change that depends on it (02668d6).

[peti]

I'll merge those fixes to release-16.090 as d59ed53d8e33e4743d5ed9486c54692ed29e289c and 69454bd15339e1ffd81a7a4e8b72c4fd97c7219a soon'ish. I'm just waiting for test build results from http://hydra.nixos.org/jobset/nixpkgs/haskell-updates.