From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 857 invoked by alias); 9 Feb 2011 07:48:40 -0000 Received: (qmail 849 invoked by uid 22791); 9 Feb 2011 07:48:39 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Feb 2011 07:48:36 +0000 From: "ktietz at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file' X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ktietz at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Resolution Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 09 Feb 2011 08:16:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-02/txt/msg01143.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 Kai Tietz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |WAITING Resolution|FIXED | --- Comment #4 from Kai Tietz 2011-02-09 07:48:27 UTC --- Hmm EACCESS is normally provided when the file has still an user (means an open handle exists to it). THere is indeed a difference between POSIX unlink and MS variant. For POSIX it is possible to call unlink on an opened file, which gets removed when last handle to it is closed. This behavior doesn't exist for win32 native API. So we need to investigate who (and why) handle to this file is still accessed. The cause for this is pretty likely to be searched in binutils.