http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #5 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-02-09 09:40:28 UTC --- So it seems to be an issue of lto and file-caching. There is a dangling file-handle, which can cause this issue. Could you please test the following patch, if it solves the unlink issue? Please make sure that lto-plugin is unmodified version. Thanks in advance, Kai Index: lto.c =================================================================== --- lto.c (revision 169962) +++ lto.c (working copy) @@ -593,7 +593,11 @@ fd_name = xstrdup (file_data->file_name); fd = open (file_data->file_name, O_RDONLY|O_BINARY); if (fd == -1) - return NULL; + { + free (fd_name); + fd_name = NULL; + return NULL; + } } #if LTO_MMAP_IO @@ -619,9 +623,17 @@ || read (fd, result, len) != (ssize_t) len) { free (result); - return NULL; + result = NULL; } - +#ifdef __MINGW32__ + /* Native windows doesn't supports delayed unlink on opened file. So + We close file here again. This produces higher I/O load, but at least + it prevents to have dangling file handles preventing unlink. */ + free (fd_name); + fd_name = NULL; + close (fd); + fd = -1; +#endif return result; #endif }