https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527
--- Comment #2 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Hm, but the COLLECT_GCC_OPTIONS variable is only used for communicating
> between the driver and the linker, the options therein are individually
> passed to the program execved?
AFAIU the driver sets `COLLECT_GCC_OPTIONS` variable and never unsets it. As a
result it affects all the `exevce() calls. Be it `cc1`, `as` or anything else
regardless of the fact if it uses the variable or not. `cc1` is probably the
first casualty.
As a simplistic example here we break `ls` with too large environment file:
$ COLLECT_GCC_OPTIONS=$(printf "%0*d" 200000 0) ls
-bash: /run/current-system/sw/bin/ls: Argument list too long
> You are maybe looking for the -f*-map options to take a file as input
> containing multiple mappings?
`NixOS` is also occasionally hottong the same limit by passing too many include
an library paths:
-I/nix/store/hash1-foo/include
-I/nix/store/hash2-bar/include
...
-L/nix/store/hash1-foo/lib
-L/nix/store/hash2-bar/lib
...
-Wl,-rpath,/nix/store/hash1-foo/lib
-Wl,-rpath,/nix/store/hash2-bar/lib
I wonder if we could solve all of these limitations here by at least avoiding
`COLLECT_GCC_OPTIONS`.
But otherwise if generic fix is too invasive change then passing a mapping file
should do as well.
What would be an acceptable for of the file? A new option, like?
-fmacro-prefix-map-file=./foo
with entries of exactly the same form
$ cat foo
/nix/store/hash1-foo=/nix/store/00000000-foo
/nix/store/hash2-bar=/nix/store/00000000-bar
...
Or maybe reuse existing -fmacro-prefix-map= and use response-style file input?
Like -fmacro-prefix-map=@./foo.
clang would probably need the same handling if we were to extend the driver.
