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
}