* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
@ 2011-01-10 14:37 ` coolypf at qq dot com
2011-02-08 15:41 ` ktietz at gcc dot gnu.org
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: coolypf at qq dot com @ 2011-01-10 14:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #1 from coolypf <coolypf at qq dot com> 2011-01-10 13:59:45 UTC ---
same problem on mingw-w64, with error message:
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc64.exe
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.6-20110108/configure --prefix=/gcc4 --enable-threads
--disable-nls --disable-win32-registry --disable-werror --disable-shared
--disable-bootstrap --disable-multilib --disable-libquadmath
--with-ld=/x86_64-w64-mingw32/bin/ld --with-as=/x86_64-w64-mingw32/bin/as
--target=x86_64-w64-mingw32
Thread model: win32
gcc version 4.6.0 20110108 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=x86-64'
d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/cc1.exe -quiet -v
-iprefix d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/ test.c -quiet
-dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -version -flto -o
C:\Users\coolypf\AppData\Local\Temp\ccWy8m2U.s
GNU C (GCC) version 4.6.0 20110108 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/sys-include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.6.0/include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.6.0/include-fixed"
ignoring nonexistent directory
"d:/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/sys-include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/include
d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/include-fixed
d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C (GCC) version 4.6.0 20110108 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8be092602fa0cd5a35bfde8b7f46ede4
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=x86-64'
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/as.exe
-v -o C:\Users\coolypf\AppData\Local\Temp\ccc16uMR.o
C:\Users\coolypf\AppData\Local\Temp\ccWy8m2U.s
GNU assembler version 2.21.51 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.21.51.20110109
COMPILER_PATH=d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=x86-64'
d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/collect2.exe -plugin
d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/liblto_plugin-0.dll
-plugin-opt=d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\coolypf\AppData\Local\Temp\cckhpf6R.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -flto -m
i386pep -Bdynamic
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/crtbegin.o
-Ld:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0 -Ld:/mingw/bin/../lib/gcc
-Ld:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib
-Ld:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib
C:\Users\coolypf\AppData\Local\Temp\ccc16uMR.o -lmingw32 -lgcc -lmoldname
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc
-lmoldname -lmingwex -lmsvcrt
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/crtend.o
D:\MinGW\bin\gcc64.exe @C:\Users\coolypf\AppData\Local\Temp\ccycZkKe.args
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc64.exe
COLLECT_LTO_WRAPPER=d:/mingw/lib/gcc/../../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.6-20110108/configure --prefix=/gcc4 --enable-threads
--disable-nls --disable-win32-registry --disable-werror --disable-shared
--disable-bootstrap --disable-multilib --disable-libquadmath
--with-ld=/x86_64-w64-mingw32/bin/ld --with-as=/x86_64-w64-mingw32/bin/as
--target=x86_64-w64-mingw32
Thread model: win32
gcc version 4.6.0 20110108 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
'-fltrans-output-list=C:\Users\coolypf\AppData\Local\Temp\ccmGzfsc.ltrans.out'
'-fwpa' '-fresolution=C:\Users\coolypf\AppData\Local\Temp\cckhpf6R.res'
d:/mingw/lib/gcc/../../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto1.exe -quiet
-dumpbase ccc16uMR.o -mtune=generic -march=x86-64 -auxbase ccc16uMR -version
-fltrans-output-list=C:\Users\coolypf\AppData\Local\Temp\ccmGzfsc.ltrans.out
-fwpa -fresolution=C:\Users\coolypf\AppData\Local\Temp\cckhpf6R.res
@C:\Users\coolypf\AppData\Local\Temp\ccW0zfsc
GNU GIMPLE (GCC) version 4.6.0 20110108 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.6.0 20110108 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COMPILER_PATH=d:/mingw/lib/gcc/../../libexec/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/lib/gcc/../../libexec/gcc/;d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
'-fltrans-output-list=C:\Users\coolypf\AppData\Local\Temp\ccmGzfsc.ltrans.out'
'-fwpa' '-fresolution=C:\Users\coolypf\AppData\Local\Temp\cckhpf6R.res'
D:\MinGW\bin\gcc64.exe @C:\Users\coolypf\AppData\Local\Temp\cceW7ylp.args
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc64.exe
COLLECT_LTO_WRAPPER=d:/mingw/lib/gcc/../../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.6-20110108/configure --prefix=/gcc4 --enable-threads
--disable-nls --disable-win32-registry --disable-werror --disable-shared
--disable-bootstrap --disable-multilib --disable-libquadmath
--with-ld=/x86_64-w64-mingw32/bin/ld --with-as=/x86_64-w64-mingw32/bin/as
--target=x86_64-w64-mingw32
Thread model: win32
gcc version 4.6.0 20110108 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64' '-fltrans' '-o'
'C:\Users\coolypf\AppData\Local\Temp\ccmGzfsc.ltrans0.ltrans.o'
d:/mingw/lib/gcc/../../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto1.exe -quiet
-dumpbase ccmGzfsc.ltrans0.o -mtune=generic -march=x86-64 -auxbase-strip
C:\Users\coolypf\AppData\Local\Temp\ccmGzfsc.ltrans0.ltrans.o -version -fltrans
@C:\Users\coolypf\AppData\Local\Temp\ccyWTiti -o
C:\Users\coolypf\AppData\Local\Temp\ccWIDrMq.s
GNU GIMPLE (GCC) version 4.6.0 20110108 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.6.0 20110108 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64' '-fltrans' '-o'
'C:\Users\coolypf\AppData\Local\Temp\ccmGzfsc.ltrans0.ltrans.o'
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/as.exe
-v -o C:\Users\coolypf\AppData\Local\Temp\ccmGzfsc.ltrans0.ltrans.o
C:\Users\coolypf\AppData\Local\Temp\ccWIDrMq.s
GNU assembler version 2.21.51 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.21.51.20110109
COMPILER_PATH=d:/mingw/lib/gcc/../../libexec/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/lib/gcc/../../libexec/gcc/;d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64' '-fltrans' '-o'
'C:\Users\coolypf\AppData\Local\Temp\ccmGzfsc.ltrans0.ltrans.o'
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
could not unlink output file
collect2: ld returned 1 exit status
no problem with snapshot 20110101
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
2011-01-10 14:37 ` [Bug lto/47241] " coolypf at qq dot com
@ 2011-02-08 15:41 ` ktietz at gcc dot gnu.org
2011-02-09 3:57 ` coolypf at qq dot com
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-02-08 15:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
Kai Tietz <ktietz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2011.02.08 15:38:59
CC| |ktietz at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-02-08 15:38:59 UTC ---
Hmm, this could be related to wrapper and file-removing there.
Does this patch fixes the issue you have?
Index: lto-plugin.c
===================================================================
--- lto-plugin.c (revision 169926)
+++ lto-plugin.c (working copy)
@@ -660,12 +660,14 @@
if (arguments_file_name)
{
t = unlink (arguments_file_name);
+ if (t != 0 && errno == ENOENT) t = 0;
check (t == 0, LDPL_FATAL, "could not unlink arguments file");
}
for (i = 0; i < num_output_files; i++)
{
t = unlink (output_files[i]);
+ if (t != 0 && errno == ENOENT) t = 0;
check (t == 0, LDPL_FATAL, "could not unlink output file");
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
2011-01-10 14:37 ` [Bug lto/47241] " coolypf at qq dot com
2011-02-08 15:41 ` ktietz at gcc dot gnu.org
@ 2011-02-09 3:57 ` coolypf at qq dot com
2011-02-09 8:16 ` ktietz at gcc dot gnu.org
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: coolypf at qq dot com @ 2011-02-09 3:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
coolypf <coolypf at qq dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |FIXED
--- Comment #3 from coolypf <coolypf at qq dot com> 2011-02-09 03:32:28 UTC ---
(In reply to comment #2)
> Hmm, this could be related to wrapper and file-removing there.
>
> Does this patch fixes the issue you have?
>
> Index: lto-plugin.c
> ===================================================================
> --- lto-plugin.c (revision 169926)
> +++ lto-plugin.c (working copy)
> @@ -660,12 +660,14 @@
> if (arguments_file_name)
> {
> t = unlink (arguments_file_name);
> + if (t != 0 && errno == ENOENT) t = 0;
> check (t == 0, LDPL_FATAL, "could not unlink arguments file");
> }
>
> for (i = 0; i < num_output_files; i++)
> {
> t = unlink (output_files[i]);
> + if (t != 0 && errno == ENOENT) t = 0;
> check (t == 0, LDPL_FATAL, "could not unlink output file");
> }
It does not fix the problem.
But the following code WORKS:
if (t != 0 && errno == 13) t = 0;
Something related to unlink is not implemented in mingw.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (2 preceding siblings ...)
2011-02-09 3:57 ` coolypf at qq dot com
@ 2011-02-09 8:16 ` ktietz at gcc dot gnu.org
2011-02-09 9:56 ` ktietz at gcc dot gnu.org
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-02-09 8:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
Kai Tietz <ktietz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |WAITING
Resolution|FIXED |
--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (3 preceding siblings ...)
2011-02-09 8:16 ` ktietz at gcc dot gnu.org
@ 2011-02-09 9:56 ` ktietz at gcc dot gnu.org
2011-02-09 13:10 ` coolypf at qq dot com
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-02-09 9:56 UTC (permalink / raw)
To: gcc-bugs
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
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (4 preceding siblings ...)
2011-02-09 9:56 ` ktietz at gcc dot gnu.org
@ 2011-02-09 13:10 ` coolypf at qq dot com
2011-02-09 13:50 ` ktietz at gcc dot gnu.org
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: coolypf at qq dot com @ 2011-02-09 13:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (5 preceding siblings ...)
2011-02-09 13:10 ` coolypf at qq dot com
@ 2011-02-09 13:50 ` ktietz at gcc dot gnu.org
2011-02-09 13:53 ` coolypf at qq dot com
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-02-09 13:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #7 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-02-09 13:10:24 UTC ---
So there seems to be another dangling file-handle on it ... you are sure new
plugin was used by ld? Another thing of interest, is the file it tries to
remove still existing or already removed, and if existing what access-rights it
has?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (6 preceding siblings ...)
2011-02-09 13:50 ` ktietz at gcc dot gnu.org
@ 2011-02-09 13:53 ` coolypf at qq dot com
2011-02-09 13:59 ` coolypf at qq dot com
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: coolypf at qq dot com @ 2011-02-09 13:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #8 from coolypf <coolypf at qq dot com> 2011-02-09 13:50:15 UTC ---
(In reply to comment #7)
> So there seems to be another dangling file-handle on it ... you are sure new
> plugin was used by ld? Another thing of interest, is the file it tries to
> remove still existing or already removed, and if existing what access-rights it
> has?
The filename is something like 'ccGQSy8u.ltrans0.ltrans.o'.
It still exists in TEMP dir.
The file is created by:
lto1.exe -quiet -dumpbase ccGQSy8u.ltrans0.o -mtune=generic -march=pentiumpro
-auxbase-strip ccGQSy8u.ltrans0.ltrans.o -version -fltrans @cckZmRUy -o
ccuOzyFX.s
as -v -o ccGQSy8u.ltrans0.ltrans.o ccuOzyFX.s
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (7 preceding siblings ...)
2011-02-09 13:53 ` coolypf at qq dot com
@ 2011-02-09 13:59 ` coolypf at qq dot com
2011-02-10 9:34 ` ktietz at gcc dot gnu.org
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: coolypf at qq dot com @ 2011-02-09 13:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #9 from coolypf <coolypf at qq dot com> 2011-02-09 13:53:17 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > So there seems to be another dangling file-handle on it ... you are sure new
> > plugin was used by ld? Another thing of interest, is the file it tries to
> > remove still existing or already removed, and if existing what access-rights it
> > has?
>
> The filename is something like 'ccGQSy8u.ltrans0.ltrans.o'.
> It still exists in TEMP dir.
>
> The file is created by:
>
> lto1.exe -quiet -dumpbase ccGQSy8u.ltrans0.o -mtune=generic -march=pentiumpro
> -auxbase-strip ccGQSy8u.ltrans0.ltrans.o -version -fltrans @cckZmRUy -o
> ccuOzyFX.s
>
> as -v -o ccGQSy8u.ltrans0.ltrans.o ccuOzyFX.s
So, I don't think the bug is related to lto1.exe,
because it doesn't produce .o files.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (8 preceding siblings ...)
2011-02-09 13:59 ` coolypf at qq dot com
@ 2011-02-10 9:34 ` ktietz at gcc dot gnu.org
2011-02-11 3:01 ` dongsheng.song at gmail dot com
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-02-10 9:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #10 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-02-10 08:57:27 UTC ---
Author: ktietz
Date: Thu Feb 10 08:57:24 2011
New Revision: 169999
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169999
Log:
2011-02-10 Kai Tietz <kai.tietz@onevision.com>
PR lto/47241
* lto.c (lto_read_section_data): Free
fd_name in failure case.
For mingw targets don't hash file-descriptor.
(read_cgraph_and_symbols): Close current_lto_file
in failure case.
Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (9 preceding siblings ...)
2011-02-10 9:34 ` ktietz at gcc dot gnu.org
@ 2011-02-11 3:01 ` dongsheng.song at gmail dot com
2011-02-11 10:01 ` ktietz at gcc dot gnu.org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dongsheng.song at gmail dot com @ 2011-02-11 3:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
Dongsheng Song <dongsheng.song at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dongsheng.song at gmail dot
| |com
--- Comment #11 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-02-11 02:36:22 UTC ---
(In reply to comment #10)
> Author: ktietz
> Date: Thu Feb 10 08:57:24 2011
> New Revision: 169999
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169999
> Log:
> 2011-02-10 Kai Tietz <kai.tietz@onevision.com>
>
> PR lto/47241
> * lto.c (lto_read_section_data): Free
> fd_name in failure case.
> For mingw targets don't hash file-descriptor.
> (read_cgraph_and_symbols): Close current_lto_file
> in failure case.
>
>
> Modified:
> trunk/gcc/lto/ChangeLog
> trunk/gcc/lto/lto.c
No, this commit still not resolve the issue.
The filename is something like 'cc8dHzVI.ltrans0.ltrans.o', tt still exists in
TEMP dir like 'C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp' .
The file is created by:
COLLECT_GCC_OPTIONS='-c' '-O2' '-pipe' '-s' '-v' '-v' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-fltrans' '-o'
'C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\cc8dHzVI.ltrans0.ltrans.o' '-shared-libgcc'
c:/gcc-4.6-windows/lib/gcc/../../libexec/gcc/i686-w64-mingw32/4.6.0/lto1.exe
-quiet -dumpbase cc8dHzVI.ltrans0.o -mtune=generic -march=x86-64 -auxbase-strip
C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\cc8dHzVI.ltrans0.ltrans.o -O2 -version
-fltrans @C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\ccseSWUb -o - |
c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/as.exe
-o C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\cc8dHzVI.ltrans0.ltrans.o
COLLECT_GCC_OPTIONS='-c' '-O2' '-pipe' '-s' '-v' '-v' '-v' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-fltrans' '-o'
'C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\cc8dHzVI.ltrans0.ltrans.o' '-shared-libgcc'
c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/ld.exe:
could not unlink output file
collect2: ld returned 1 exit status
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (10 preceding siblings ...)
2011-02-11 3:01 ` dongsheng.song at gmail dot com
@ 2011-02-11 10:01 ` ktietz at gcc dot gnu.org
2011-02-14 10:32 ` ktietz at gcc dot gnu.org
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-02-11 10:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #12 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-02-11 08:55:14 UTC ---
Yes, I know. The other part is related to binutils itself.
I just want to wait that patch for ld gets approval and a final test can be
done. AFAICS are now all issues in gcc already addressed.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (11 preceding siblings ...)
2011-02-11 10:01 ` ktietz at gcc dot gnu.org
@ 2011-02-14 10:32 ` ktietz at gcc dot gnu.org
2011-02-15 1:25 ` dongsheng.song at gmail dot com
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-02-14 10:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #13 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-02-14 10:30:15 UTC ---
So, necessary patch is now committed to binutils. Could you please retest this
issue with a recent binutils/HEAD version?
Thanks in advance,
Kai
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (12 preceding siblings ...)
2011-02-14 10:32 ` ktietz at gcc dot gnu.org
@ 2011-02-15 1:25 ` dongsheng.song at gmail dot com
2011-02-15 1:30 ` dongsheng.song at gmail dot com
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dongsheng.song at gmail dot com @ 2011-02-15 1:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #14 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-02-15 01:24:02 UTC ---
(In reply to comment #13)
> So, necessary patch is now committed to binutils. Could you please retest this
> issue with a recent binutils/HEAD version?
>
> Thanks in advance,
> Kai
Thanks, gcc/g++ can link no erros. but during a simple test,
Hello.cpp.exe can run as expected,
Hello.c.exe runing error with NULL pointer.
C:\>g++ -pipe -O2 -flto -o Hello.c.exe Hello.c
C:\>g++ -pipe -O2 -flto -o Hello.cpp.exe Hello.cpp
C:\>Hello.cpp.exe
Hello, Wolrd!
C:\>Hello.c.exe
<Pop up a NULL pointer dialog>
C:\>type Hello.cpp
#include <iostream>
int main()
{
std::cout << "Hello, Wolrd!" << std::endl;
return 0;
}
C:\>type Hello.c
#include <stdio.h>
int main()
{
printf("Hello, World!\n");
return 0;
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (13 preceding siblings ...)
2011-02-15 1:25 ` dongsheng.song at gmail dot com
@ 2011-02-15 1:30 ` dongsheng.song at gmail dot com
2011-02-15 2:46 ` dongsheng.song at gmail dot com
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dongsheng.song at gmail dot com @ 2011-02-15 1:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #15 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-02-15 01:25:18 UTC ---
Created attachment 23345
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23345
Hello.c.exe running with NULL pointer error
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (14 preceding siblings ...)
2011-02-15 1:30 ` dongsheng.song at gmail dot com
@ 2011-02-15 2:46 ` dongsheng.song at gmail dot com
2011-02-15 4:55 ` dongsheng.song at gmail dot com
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dongsheng.song at gmail dot com @ 2011-02-15 2:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #16 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-02-15 02:42:31 UTC ---
(In reply to comment #13)
> So, necessary patch is now committed to binutils. Could you please retest this
> issue with a recent binutils/HEAD version?
>
> Thanks in advance,
> Kai
I don't known if this is a binutils issue, I use gcc trunk and binutils trunk:
$ svn info vcs/svn/gcc/trunk/
Path: vcs/svn/gcc/trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 170159
Node Kind: directory
Schedule: normal
Last Changed Author: redi
Last Changed Rev: 170159
Last Changed Date: 2011-02-15 07:51:07 +0800 (Tue, 15 Feb 2011)
$ git log -1
commit 47fcd70b56abc1d5f158ac488362337a8b26f577
Author: Alan Modra <amodra@bigpond.net.au>
Date: Mon Feb 14 23:00:05 2011 +0000
daily update
$ i686-w64-mingw32-g++ Hello.cpp
/tmp/ccbwXfkL.o:Hello.cpp:(.text+0x19): undefined reference to `std::cout'
/tmp/ccbwXfkL.o:Hello.cpp:(.text+0x1e): undefined reference to
`std::basic_ostream<char, std::char_traits<char> >& std::operator<<
<std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&,
char const*)'
/tmp/ccbwXfkL.o:Hello.cpp:(.text+0x26): undefined reference to
`std::basic_ostream<char, std::char_traits<char> >& std::endl<char,
std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)'
/tmp/ccbwXfkL.o:Hello.cpp:(.text+0x2e): undefined reference to
`std::basic_ostream<char, std::char_traits<char>
>::operator<<(std::basic_ostream<char, std::char_traits<char> >&
(*)(std::basic_ostream<char, std::char_traits<char> >&))'
/tmp/ccbwXfkL.o:Hello.cpp:(.text+0x47): undefined reference to
`std::ios_base::Init::~Init()'
/tmp/ccbwXfkL.o:Hello.cpp:(.text+0x6a): undefined reference to
`std::ios_base::Init::Init()'
collect2: ld returned 1 exit status
But when I use static link, no errors:
$ i686-w64-mingw32-g++ -static Hello.cpp
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (15 preceding siblings ...)
2011-02-15 2:46 ` dongsheng.song at gmail dot com
@ 2011-02-15 4:55 ` dongsheng.song at gmail dot com
2011-02-15 8:15 ` ktietz at gcc dot gnu.org
2011-02-15 8:33 ` dongsheng.song at gmail dot com
18 siblings, 0 replies; 20+ messages in thread
From: dongsheng.song at gmail dot com @ 2011-02-15 4:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #17 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-02-15 02:46:14 UTC ---
It seems that libstdc++.dll.a is too small:
$ file gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a
gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a: current ar
archive
$ ls -l gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a
-rwxr-xr-x 1 oracle dba 2260 Feb 15 10:34
gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a
$ i686-w64-mingw32-g++ Hello.cpp
gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a
/tmp/cc39V2U9.o:Hello.cpp:(.text+0x19): undefined reference to `std::cout'
/tmp/cc39V2U9.o:Hello.cpp:(.text+0x1e): undefined reference to
`std::basic_ostream<char, std::char_traits<char> >& std::operator<<
<std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&,
char const*)'
/tmp/cc39V2U9.o:Hello.cpp:(.text+0x26): undefined reference to
`std::basic_ostream<char, std::char_traits<char> >& std::endl<char,
std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)'
/tmp/cc39V2U9.o:Hello.cpp:(.text+0x2e): undefined reference to
`std::basic_ostream<char, std::char_traits<char>
>::operator<<(std::basic_ostream<char, std::char_traits<char> >&
(*)(std::basic_ostream<char, std::char_traits<char> >&))'
/tmp/cc39V2U9.o:Hello.cpp:(.text+0x47): undefined reference to
`std::ios_base::Init::~Init()'
/tmp/cc39V2U9.o:Hello.cpp:(.text+0x6a): undefined reference to
`std::ios_base::Init::Init()'
collect2: ld returned 1 exit status
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (16 preceding siblings ...)
2011-02-15 4:55 ` dongsheng.song at gmail dot com
@ 2011-02-15 8:15 ` ktietz at gcc dot gnu.org
2011-02-15 8:33 ` dongsheng.song at gmail dot com
18 siblings, 0 replies; 20+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-02-15 8:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
Kai Tietz <ktietz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |FIXED
--- Comment #18 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-02-15 08:03:05 UTC ---
Well, I see the issue you are describing here, but it isn't any longer related
to this PR. So please open an new PR for it.
So I close this bug as fixed.
Regards,
Kai
PS:I assume that you won't have the issue by using -static option on gcc
command-line.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
2011-01-10 11:52 [Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file' coolypf at qq dot com
` (17 preceding siblings ...)
2011-02-15 8:15 ` ktietz at gcc dot gnu.org
@ 2011-02-15 8:33 ` dongsheng.song at gmail dot com
18 siblings, 0 replies; 20+ messages in thread
From: dongsheng.song at gmail dot com @ 2011-02-15 8:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #19 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-02-15 08:23:35 UTC ---
(In reply to comment #18)
> Well, I see the issue you are describing here, but it isn't any longer related
> to this PR. So please open an new PR for it.
>
> So I close this bug as fixed.
>
> Regards,
> Kai
>
> PS:I assume that you won't have the issue by using -static option on gcc
> command-line.
No, maybe the another bug mix up you eyes:-)
Even for static link, lto still not works fine for Hello.c:
C:\>g++ -pipe -O2 -flto -o Hello.c.exe Hello.c
C:\>Hello.c.exe
<Pop up a NULL pointer dialog>
C:\>g++ -pipe -O2 -flto -static -o Hello.c.static.exe Hello.c
C:\>Hello.c.static.exe
<Pop up a NULL pointer dialog>
C:\>g++ -pipe -O2 -o Hello.exe Hello.c
C:\>Hello.exe
Hello, World!
^ permalink raw reply [flat|nested] 20+ messages in thread