Created attachment 30063 [details] Output of -v -save-temps invokation The following code when compiled with gcc 4.9.0 20130505 (experimental) using mingw 64 bit using the compiler flags -Wall (with or without -std=c++11 or -pedantic-errors) causes a linker error: //-------------------------------------- #include <iostream> int main() {} //-------------------------------------- "c:\program files\develop\gcc\bin\..\lib\gcc\x86_64-w64-mingw32\4.9.0\..\..\..\..\lib\libstdc++.a(c++locale.o)||In function `strtod':| \home\gfortran\gcc-home\binary\mingw32\native\x86_64\gcc\4.9-20130505\x86_64-w64-mingw32\include\stdlib.h|392|undefined reference to `__mingw_strtod'"
I should add that the link error occurs whether or whether not the -m32 flag is provided to the compiler and linker
Kai, do you have any idea what may go wrong here?
Well, I see that this symbol is part of our libmingwex.a library on trunk. For gcc 4.8 and above it is recommented to use 3.0 runtime-version for w64. I assume you are using 2.x crt version and having 3.x headers. A simple test for checking what mingw-w64 runtime you are using in fact is by compiling the following code and execute it: #include <stdio.h> int main() { printf ("%s\n", __mingw_get_crt_info ()); return 0; }
I don't need it twice
(In reply to comment #3) Thanks for the litmus test, Kay. The result output I'm getting is: MinGW-W64 Runtime 3.0 (alpha - rev. 0) 0000-00-00 so it seems this is indeed the version 3.0.
Fine, by which date this version was built? I am pretty curious to see that issue for 4.9 due I don't happen to see it on my box. Could you check, if libmingwex.a contains for you the symbol in question? For me $ x86_64-w64-mingw32-nm.exe /usr/local/x86_64-w64-mingw32/lib/libmingwex.a | grep -e "__mingw_strtod" displays: 0000000000000000 T __mingw_strtod and shows symbol is present.
(In reply to comment #6) The attached '-v' '-save-temps' output indicates version 4.9.0 20130505 (experimental) (x86_64-w64-mingw32), but I'm not sure whether this is reliable in this context. The libmingwex.a file contains the string pattern __mingw_strtod twice, here the contexts of the findings: __tinytens_D2A __strtod __mingw_strtod __strtof __mingw_strtof 3 .rdata$zzz __mingw_strtod .rdata$zzz __strtodg /1900 The spaces shown here are actually NUL values. Is this information sufficiently precise?
Well, you should us the nm tool to check for existance of a symbol. Grepping for strings might lead you to wrong direction. I don't see anything obviously wrong on you temp-file. The only thing I am a bit confused about is that there seems to be a 4.7.2 directory used for crtend object ... so it looks to me that you might be still using two different runtimes and mixing stuff here happily. I just did a rebuild of all required stuff and I can't reproduce this issue. The options you've shown initially have for sure nothing to do with link-order, or about use of libraries.
(In reply to comment #8) > Well, you should us the nm tool to check for existance of a symbol. Grepping > for strings might lead you to wrong direction. My apologies, I had seen the "grep" and misinterpreted what you are asking for. I can't find the exact tool named x86_64-w64-mingw32-nm.exe, but nm.exe instead and it gave me also 0000000000000000 T __mingw_strtod > I don't see anything obviously wrong on you temp-file. The only thing I am a > bit confused about is that there seems to be a 4.7.2 directory used for crtend > object ... so it looks to me that you might be still using two different > runtimes and mixing stuff here happily. Ouch - I didn't notice that! This indeed looks like a potential candidate for the actual root of problem! > I just did a rebuild of all required stuff and I can't reproduce this issue. > The options you've shown initially have for sure nothing to do with link-order, > or about use of libraries. Thanks very much for all your help. I will proceed tomorrow following the potential "gcc-4.7.2" path problem.
I couldn't resist and removed all gcc entries from the env PATH, which solved the problem. I apologize for the unnecessary trouble I have caused - at least I learned several new things about mingw.