compiler: keep the wrappers out of the compiler's own PATH - #36
Merged
Merged
Conversation
The wrapper directory goes on PATH so the build's `clang` is this recorder. ccache is normally used the same way, through a directory of symlinks named after the compilers, and works out which compiler to run by looking its own name up on PATH again, skipping only itself. It therefore found the wrapper, which handed straight back to ccache, which found the wrapper: neither ever stopped, and each pass appended another `-ftime-trace` to a command line that grew without bound. The directory is there to intercept what the build launches, not what the compiler launches, so take it back out of PATH before handing over. Fixes #26
The suite requires every tool it names, so the wrapper loop test needs both present rather than skipped.
This was referenced Sep 16, 2026
Merged
LalitMaganti
added a commit
that referenced
this pull request
Sep 16, 2026
`main` is red. Installing ccache for the wrapper loop test (#36) put `/usr/lib/ccache` in front of `cc` on the CI runner, since the Ubuntu package populates that directory and the runner already has it on `PATH`. The build-system diff tests inherit the whole environment, so ccache ran as part of every build and each expectation grew a `ccache` node and an `as -> ccache [.o]` edge. The expectations describe a plain toolchain, so record with one: take any launcher directory off `PATH` for these recordings. Tests that want a launcher, such as the wrapper loop test, put one there themselves. Verified on Linux by reproducing the CI condition with `/usr/lib64/ccache` first on `PATH`: `make` fails before the change and passes after, and the suite is 43 passed, 3 skipped with it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #26.
The wrapper directory goes on
PATHso that the build'sclangis thisrecorder. ccache is normally used the same way, through a directory of
symlinks named after the compilers, and works out which compiler to run by
looking its own name up on
PATHagain, skipping only itself. It thereforefinds the wrapper, which hands straight back to ccache, which finds the
wrapper.
ccache's own log, with
/usr/lib64/ccachefirst onPATH:ccache's recursion guard does fire, but its escape hatch is to run the real
compiler in place, and the real compiler is the wrapper again, so the guard
feeds the loop rather than breaking it. Each pass also appends another
-ftime-trace, so the command line grows without bound: over a hundredcopies in one argv after a few seconds, ending in
E2BIGrather than anerror anyone can read.
The directory is there to intercept what the build launches, not what the
compiler launches, so take it back out of
PATHbefore handing over. ccachethen resolves
clangthe way it does without buildprof. The same applies todistcc and icecream, which pick the compiler the same way.