when use g++ to build wxWidgets in x86_64-pc-mingw32, it output following error : ------------------ E:\work\09_workroom\wxtest\png>mingw32-make -f Makefile.mingw WX_DIR=e:\code\wx6 4 CXX=e:\code\target\bin\g++.exe e:\code\target\bin\g++.exe -g -Wall -pipe -D__WXMSW__ -D__WXDEBUG__ -DWIN32 -D_ WINDOWS -Ie:\code\wx64/include -Ie:\code\wx64/lib/mswd png.o stdafx.o -o png.e xe -mwindows -Le:\code\wx64/lib -lwxmsw28d_core -lwxbase28d -lwxpngd -lwxzlibd - lgdi32 -lole32 -loleaut32 -lwinmm -lcomctl32 -lcomdlg32 -lwinspool -luuid -lshel l32 -lrpcrt4 e:/code/target/bin/../lib/gcc/x86_64-pc-mingw32/4.3.2/../../../../x86_64-pc-ming w32/lib/libmingwex.a(lib64_libmingwex_a-wininterlocked.o):wininterlocked.c:(.tex t+0x43b): multiple definition of `_InterlockedIncrement' e:\code\wx64/lib/libwxbase28d.a(baselib_thread.o):thread.cpp:(.text$_Interlocked Increment[__InterlockedIncrement]+0x0): first defined here e:/code/target/bin/../lib/gcc/x86_64-pc-mingw32/4.3.2/../../../../x86_64-pc-ming w32/lib/libmingwex.a(lib64_libmingwex_a-wininterlocked.o):wininterlocked.c:(.tex t+0x487): multiple definition of `_InterlockedDecrement' e:\code\wx64/lib/libwxbase28d.a(baselib_thread.o):thread.cpp:(.text$_Interlocked Decrement[__InterlockedDecrement]+0x0): first defined here collect2: ld returned 1 exit status mingw32-make: *** [png.exe] Error 1 ----------------- _InterlockedDecrement is an inline function, it should not in baselib_thread.o, when built with "-O1", its ok. when built with "-O2", g++ crashed. see attachment for more infomation.
Created attachment 16405 [details] output of gcc -E
Created attachment 16406 [details] output of nm, the object is build by gcc -O0
Created attachment 16407 [details] output of nm, the object is build by gcc -O1
Created attachment 16408 [details] output of objdump, the object is build by gcc -O0
Created attachment 16409 [details] output of objdump, the object is build by gcc -O1
What is the output of g++ -v? Are you using the win32 cross compiler, or the win64 native compiler?
I'm using the win64 native compiler: E:\code>g++ -v Using built-in specs. Target: x86_64-pc-mingw32 Configured with: ../gcc/configure --host=x86_64-pc-mingw32 --target=x86_64-pc-mi ngw32 --disable-nls --enable-languages=c,c++ --with-gmp=/home/drangon/mingw/for_ target --enable-twoprocess --prefix=/home/drangon/mingw/target --with-sysroot=/h ome/drangon/mingw/target Thread model: win32 gcc version 4.4.0 20080814 (experimental) (GCC)
I can't test your precompiled code, because c++ has changed in an incompatible way. Could you attach a current precompiled version using gcc4.4 of it? Is the problem still present on 4.4.0 ?
(In reply to comment #8) > I can't test your precompiled code, because c++ has changed in an incompatible > way. Could you attach a current precompiled version using gcc4.4 of it? > Is the problem still present on 4.4.0 ? > I built the native toolchain using the newest source code, the problem still present.
Created attachment 17413 [details] gcc -E output ( gcc 4.4.0 svn 20090307 )
Created attachment 17414 [details] the output object of thread.o
Was this broken in 4.3 compilers? Is it a 4.4 regression?
(In reply to comment #12) > Was this broken in 4.3 compilers? Is it a 4.4 regression? > This is not a new bug in the compiler (the same multiple definition will occur with 3.4.5) , but an old 'feature' of the the PE-COFF linker _InterlockedIncrement is defined as an ordinary C library function in lib64_libmingwex_a-wininterlocked.o In thread.cpp, it is defined and emitted using linkonce semantics (it is put into its own .text$_InterlockedIncrement link_once sections, which is how PE-COFF implements vague linkage. The linker grabs the one and only .text$_InterlockedIncrement section in thread.o and then while resolving another symbol it needs from lib64_libmingwex_a-wininterlocked.o finds an ordinary (not .linkonce) definition InterlockedIncrement Hence the multiple definition.
how to fix this multiple definition issue ? adjust the linker to allow this ? or remove the ordinary C library function in lib64_libmingwex_a-wininterlocked.o and just keep the inline function ? or remove the inline function, replace by a function declaration which use the implementation from lib64_libmingwex_a-wininterlocked.o ?
(In reply to comment #14) > or remove the ordinary C library function in > lib64_libmingwex_a-wininterlocked.o and just keep the inline function ? > That would be my first experiment. What depends on lib64_libmingwex_a-wininterlocked.o Danny
(In reply to comment #15) > (In reply to comment #14) > > or remove the ordinary C library function in > > lib64_libmingwex_a-wininterlocked.o and just keep the inline function ? > > > That would be my first experiment. What depends on > lib64_libmingwex_a-wininterlocked.o > Danny we implemented int wininterlocked.c file the common interlocked symbols, because some of them should be inlined for performance reasons. To remove the inline version seems to be the best solution for me here. Because otherwise we would disallow a function pointer reference to it. Possibly we could make als define those symbols in wininterlocked.c as weak, does this help? Kai
Ah, C++ makes here the trouble. We found the same issue about math.h. Here I fixed it by avoiding to define the inline functions for C++. I assumed it was fixed already, but this doesn't seem so. It seems that in C++ the meaning of inline functions in extern "C" blocks has altered by intention, or this regression still exists. Kai
This bug is fixed by a recent change to our runtime headers. We support now the NO_INLINE feature for platform headers, too. So, even intrinsic functions aren't emitted anymore, when __NO_INLINE__ is defined.