gcc leaves undeleted temporary files when invoked with a response file
Split off from #10986.
In changeset:296bc70b (present in 7.10.3, but not 7.10.2) ghc started using response files when invoking gcc as a linker, to work around command-line length limits.
Unfortunately, gcc leaves behind a temporary file /tmp/cc?????? when it is invoked with a response file. That means that every time we link an executable, gcc leaks a temporary file. In the course of a validate run (due mainly to the testsuite) that means thousands of temporary files.
I'm not sure exactly which versions (or which OSes) are affected, but from ticket:10986#comment:108586 it seems that at least gcc 4.6.3 on Windows is affected, and Windows is where we need the response file the most (since the command line length limit is shortest there).
slyfox filed an upstream bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69351
But in the mean time, this is pretty terrible. What can we do about it?
One suggestion: ghc already creates a temporary directory like /tmp/ghc1740_0. So make a subdirectory /tmp/ghc1740_0/cc, and set TMPDIR (or whichever similarly-named environment variable has highest precedence) for the invocation of gcc to that directory. Then, when cleaning up, we blow away that whole directory. Then we are immune to gcc leaving behind any temporary files.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |