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

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

[coolypf at qq dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241

           Summary: lto not work on mingw32, reporting 'ld.exe: could not
                    unlink output file'
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: coolypf@qq.com


gcc 4.6.0 snapshot 20110108
compile following code with 'gcc-4 -v -flto test.c'

#include <stdio.h>
int main()
{
    printf("Test\n");
    return 0;
}

and get the following error message:

Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc-4.exe
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.6-20110108/configure --prefix=/gcc4
--program-suffix=-4 --with-gnu-as --with-gnu-ld --enable-threads
--disable-shared --disable-win32-registry --disable-werror --disable-nls
--disable-libquadmath --disable-bootstrap
Thread model: win32
gcc version 4.6.0 20110108 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=pentiumpro'
 d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/cc1.exe -quiet -v -iprefix
d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/ test.c -quiet -dumpbase test.c
-mtune=generic -march=pentiumpro -auxbase test -version -flto -o
C:\Users\coolypf\AppData\Local\Temp\ccZ46Rlb.s
GNU C (GCC) version 4.6.0 20110108 (experimental) (i686-pc-mingw32)
    compiled by GNU C version 4.6.0 20110101 (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/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/i686-pc-mingw32/4.6.0/include"
ignoring nonexistent directory "D:/MinGW/gcc4/include"
ignoring nonexistent directory "/gcc4/include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/i686-pc-mingw32/4.6.0/include-fixed"
ignoring nonexistent directory
"d:/mingw/lib/gcc/../../lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/include"
ignoring duplicate directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include
 d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/../../../../include
 d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include-fixed
End of search list.
GNU C (GCC) version 4.6.0 20110108 (experimental) (i686-pc-mingw32)
    compiled by GNU C version 4.6.0 20110101 (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: c752079cf4e558b53a88eee0a5828d49
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=pentiumpro'
 as -v -o C:\Users\coolypf\AppData\Local\Temp\cc0lkcdl.o
C:\Users\coolypf\AppData\Local\Temp\ccZ46Rlb.s
GNU assembler version 2.21.51 (i686-pc-mingw32) using BFD version (GNU
Binutils) 2.21.51.20110109
COMPILER_PATH=d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../../;/mingw/lib/
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=pentiumpro'
 d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/collect2.exe -plugin
d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/liblto_plugin-0.dll
-plugin-opt=d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\coolypf\AppData\Local\Temp\ccAKIfIl.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
-Bdynamic d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../../crt2.o
d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/crtbegin.o
-Ld:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0 -Ld:/mingw/bin/../lib/gcc
-Ld:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../.. -L/mingw/lib
C:\Users\coolypf\AppData\Local\Temp\cc0lkcdl.o -lmingw32 -lgcc -lmoldname
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc
-lmoldname -lmingwex -lmsvcrt
d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/crtend.o
 D:\MinGW\bin\gcc-4.exe @C:\Users\coolypf\AppData\Local\Temp\ccOgvLTl.args
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc-4.exe
COLLECT_LTO_WRAPPER=d:/mingw/lib/gcc/../../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.6-20110108/configure --prefix=/gcc4
--program-suffix=-4 --with-gnu-as --with-gnu-ld --enable-threads
--disable-shared --disable-win32-registry --disable-werror --disable-nls
--disable-libquadmath --disable-bootstrap
Thread model: win32
gcc version 4.6.0 20110108 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=pentiumpro'
'-fltrans-output-list=C:\Users\coolypf\AppData\Local\Temp\ccuIPX1f.ltrans.out'
'-fwpa' '-fresolution=C:\Users\coolypf\AppData\Local\Temp\ccAKIfIl.res'
 d:/mingw/lib/gcc/../../libexec/gcc/i686-pc-mingw32/4.6.0/lto1.exe -quiet
-dumpbase cc0lkcdl.o -mtune=generic -march=pentiumpro -auxbase cc0lkcdl
-version
-fltrans-output-list=C:\Users\coolypf\AppData\Local\Temp\ccuIPX1f.ltrans.out
-fwpa -fresolution=C:\Users\coolypf\AppData\Local\Temp\ccAKIfIl.res
@C:\Users\coolypf\AppData\Local\Temp\cc2biTYe
GNU GIMPLE (GCC) version 4.6.0 20110108 (experimental) (i686-pc-mingw32)
    compiled by GNU C version 4.6.0 20110101 (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) (i686-pc-mingw32)
    compiled by GNU C version 4.6.0 20110101 (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/i686-pc-mingw32/4.6.0/;d:/mingw/lib/gcc/../../libexec/gcc/;d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../../;/mingw/lib/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../../;/mingw/lib/
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=pentiumpro'
'-fltrans-output-list=C:\Users\coolypf\AppData\Local\Temp\ccuIPX1f.ltrans.out'
'-fwpa' '-fresolution=C:\Users\coolypf\AppData\Local\Temp\ccAKIfIl.res'
 D:\MinGW\bin\gcc-4.exe @C:\Users\coolypf\AppData\Local\Temp\ccK0v2Xy.args
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc-4.exe
COLLECT_LTO_WRAPPER=d:/mingw/lib/gcc/../../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.6-20110108/configure --prefix=/gcc4
--program-suffix=-4 --with-gnu-as --with-gnu-ld --enable-threads
--disable-shared --disable-win32-registry --disable-werror --disable-nls
--disable-libquadmath --disable-bootstrap
Thread model: win32
gcc version 4.6.0 20110108 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=pentiumpro' '-fltrans'
'-o' 'C:\Users\coolypf\AppData\Local\Temp\ccuIPX1f.ltrans0.ltrans.o'
 d:/mingw/lib/gcc/../../libexec/gcc/i686-pc-mingw32/4.6.0/lto1.exe -quiet
-dumpbase ccuIPX1f.ltrans0.o -mtune=generic -march=pentiumpro -auxbase-strip
C:\Users\coolypf\AppData\Local\Temp\ccuIPX1f.ltrans0.ltrans.o -version -fltrans
@C:\Users\coolypf\AppData\Local\Temp\cc0meYVk -o
C:\Users\coolypf\AppData\Local\Temp\ccQziMHv.s
GNU GIMPLE (GCC) version 4.6.0 20110108 (experimental) (i686-pc-mingw32)
    compiled by GNU C version 4.6.0 20110101 (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) (i686-pc-mingw32)
    compiled by GNU C version 4.6.0 20110101 (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=pentiumpro' '-fltrans'
'-o' 'C:\Users\coolypf\AppData\Local\Temp\ccuIPX1f.ltrans0.ltrans.o'
 as -v -o C:\Users\coolypf\AppData\Local\Temp\ccuIPX1f.ltrans0.ltrans.o
C:\Users\coolypf\AppData\Local\Temp\ccQziMHv.s
GNU assembler version 2.21.51 (i686-pc-mingw32) using BFD version (GNU
Binutils) 2.21.51.20110109
COMPILER_PATH=d:/mingw/lib/gcc/../../libexec/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/lib/gcc/../../libexec/gcc/;d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../../;/mingw/lib/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../../;/mingw/lib/
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=pentiumpro' '-fltrans'
'-o' 'C:\Users\coolypf\AppData\Local\Temp\ccuIPX1f.ltrans0.ltrans.o'
D:\MinGW\bin/ld.exe: could not unlink output file
collect2: ld returned 1 exit status

gcc 4.6.0 snapshot 20110101 works fine with '-flto'
so changes between 1/1 and 1/8 cause lto failure on mingw32

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

[coolypf at qq dot com]

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

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

[ktietz at gcc dot gnu.org]

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");
     }

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

[coolypf at qq dot com]

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.

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

[ktietz at gcc dot gnu.org]

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.

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

[ktietz at gcc dot gnu.org]

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
 }

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

[coolypf at qq dot com]

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.

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

[ktietz at gcc dot gnu.org]

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?

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

[coolypf at qq dot com]

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

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

[coolypf at qq dot com]

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.

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

[ktietz at gcc dot gnu.org]

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

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

[dongsheng.song at gmail dot com]

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

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

[ktietz at gcc dot gnu.org]

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.

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

[ktietz at gcc dot gnu.org]

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

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

[dongsheng.song at gmail dot com]

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;
}

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

[dongsheng.song at gmail dot com]

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

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

[dongsheng.song at gmail dot com]

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

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

[dongsheng.song at gmail dot com]

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

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

[ktietz at gcc dot gnu.org]

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.

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

[dongsheng.song at gmail dot com]

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!