This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
- From: "coolypf at qq dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 9 Feb 2011 12:54:55 +0000
- Subject: [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
- Auto-submitted: auto-generated
- References: <bug-47241-4@http.gcc.gnu.org/bugzilla/>
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.