A way to configure always using @argfile for linker invocations

[weihanglo]

My scenario is a bit weird.

In my build system, there is a general wrapper that disguises itself as clang. Unfortunately it doesn't really propagate the OS error well, so E2BIG won't be caught by rustc.

If the linker invocation has grown too big (which is not uncommon because Cargo always passes absolute paths for rustflags), with the general wrapper in my build system, rustc didn't know how to recover and then gave up.

error: linking with `x86_64-unknown-linux-gnu-clang` failed: exit status: 255
  |
  = note: PATH="..." "x86_64-unknown-linux-gnu-clang" "<256 object files omitted>" <1024 rlib files omitted> "-Wl,--undefined-version"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: my-wrapper: Argument list too long      

Is there a way to tell rustc always use @argfile for linker invocations?

Possible solutions

• Provide a way to tell rustc always use @argfile for linker invocations.
• Put my t-cargo hat on. Cargo maybe should stop using absolute paths and switch to relative paths, I know. But that won't fix the root problem if I then have 8192 rlib files…
• Perhaps I could try find an way to estimate the arglist length also on Unix?
  

  rust/compiler/rustc_codegen_ssa/src/back/command.rs

  Lines 140 to 144 in c53af1c

  	// We mostly only care about Windows in this method, on Unix the limits
  	// can be gargantuan anyway so we're pretty unlikely to hit them
  	if cfg!(unix) {
  	return false;
  	}

[jieyouxu]

I suppose it would be reasonable to add a rustc flag that tries to instruct rustc to always attempt to use @argfile for linker invocations with the explicit caveat that said linker must actually support it (and suport it well), and if it doesn't, well sorry.

The absolute path -> relative path is really at most a mitigation and doesn't actually help if the invocation would be truly massive.

[weihanglo]

Perhaps I could try find an way to estimate the arglist length also on Unix?

What about this? Call sysconf(_SC_ARG_MAX) and don't bother the likely-to-fail attempt.

[jieyouxu]

Seems reasonable