http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #6 from coolypf <coolypf at qq dot com> 2011-02-09 12:54:46 UTC ---
(In reply to comment #5)
> 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
> }
The patch does not take effect.
The errno before "could not unlink output file" message
in lto-plugin.c is still 13.
