This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]