LTO links lose the jobserver

[avikivity]

01c35e6 says:

Almost nothing sccache spawns can use a jobserver. It reaches a child through
CARGO_MAKEFLAGS, and only rustc reads it: preprocessors, version probes and
C/C++ compilers all ignore it. So stop sharing by default and let the callers
that spawn rustc ask, via RunCommand::share_jobserver.

But clang/gcc can use the jobserver when running an LTO link. We should continue to pass the jobserver for those jobs.

[avikivity]

cc @rnk @sylvestre

[sylvestre]

sorry but what means "lose the jobserver"?

[avikivity]

IIUC 01c35e6 closes the jobserver's file descriptors so, so the child job cannot consume tokens from them.

[badumbatish]

do you have a reproducer? would love to take a look at this

[avikivity]

I don't have a reproducer, but I'm sure Claude will generate on in a minute.

[sylvestre]

sorry but what is the actual issue then ?

[ishitatsuyuki]

I come across this when looking at 01c35e6, which does fix a massive perf hog. But I don't think sccache handles linking at all? So I don't see how this is an issue.

[avikivity]

If sccache receives a link command from the build system using the clang or gcc wrapper, then it will invoke the link command verbatim (without caching). But it will still kill the jobserver file descriptors when it launches it.

For example, my build.ninja has:

cxx = /usr/local/bin/sccache /usr/local/bin/clang++
rule link.dev
  command = $cxx  $ld_flags_dev $ldflags -o $out $in $libs $libs_dev

So links will pass through sccache. I guess I could fix it easily for myself, but there could be plenty of others that are vulnerable.