#11476: gcc leaves undeleted temporary files when invoked with a response file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Split off from #10986. In changeset:296bc70b5ff6c853f2782e9ec5aa47a52110345e (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:5 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11476 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler