From: Eli Z. <el...@gn...> - 2013-03-29 10:29:03
|
> Date: Fri, 29 Mar 2013 13:43:09 +0400 > From: LRN <lr...@gm...> > Cc: Ben Elliston <bj...@ai...> > > Forwarding to mingw-users (i know that some mingw-w64 developers are > subscribed as well, so no need to CC to mingw-w64 ML, i guess). Caveat: I'm not a MinGW developer, just a (happy) user. And that includes MSYS. > > I've noticed that config.guess will always detect my system as: > > i686-pc-mingw32. Turns out: 1) -pc vendor name is hard-coded into > > config.guess 2) config.guess relies on uname to get machine > > architecture > > > > Both are wrong, because: 1) mingw-w64 toolchain has -w64 vendor > > name, but can (and should) still be used with MSYS. uname is a > > MSYS-only utility, and has no knowledge of the mingw toolchain > > installed alongside it. Thus uname can't tell a difference between > > MSYS+mingw.org toolchain and MSYS+mingw-w64 toolchain. While it > > might (didn't test that) be possible to modify msys configuration > > to identify itself differently, it would have to be enforced from > > outside, and would still have nothing to do with the toolchain. > > > > 2) uname only reports MSYS architecture. MSYS (at the moment; not > > sure about MSYS2) is 32-bit only, and will always report itself as > > either i386 or i686 (could also claim to be "alpha" or "mips", but > > that's exotic) based upon GetSystemInfo() API call results. Even if > > it had been capable of correctly identifying x86_64 versions of the > > OS, that still would be somewhat at odds with the toolchain, > > because x86_64 Windows can run both x86 and x86_64 toolchains. It > > is better to ask the toolchain about its architecture. > > > > To this end, *:MINGW*:* case should not default to > > ${UNAME_MACHINE}-pc-mingw32, but should instead run CC like some > > other tests do, and check for the following preprocessor > > definitions: __MINGW32_MAJOR_VERSION __MINGW64_VERSION_MAJOR > > __MINGW32__ __MINGW64__ > > > > __MINGW32__ is defined by all mingw toolchains, both x86 and > > x86_64, from both vendors (mingw.org and mingw-w64). If it isn't > > there, it's not mingw. Defined by gcc internally. > > > > __MINGW64__ is only defined by x86_64 toolchains (currently only > > mingw-w64, but mingw.org might catch up in the future) alongside > > with __MINGW32__. Defined by gcc internally. > > > > __MINGW64_VERSION_MAJOR is only defined by mingw-w64 headers (same > > headers used for both x86 and x86_64). Defined by headers, so you > > need to include a standard header (such as stdio.h) for it to > > appear. > > > > __MINGW32_MAJOR_VERSION is only defined by mingw.org headers. > > Defined by headers, so you need to include a standard header (such > > as stdio.h) for it to appear. > > > > A proof-of-concept patch is attached. Thanks. A few comments below. First, you are using an MSYS/MinGW32 hosting environment to build MinGW64 executables. In effect, this means you are cross-compiling. AFAIK, the build configuration for cross compilations are specified via the "--build" switch to configure script, precisely because 'uname' cannot possibly return it correctly, unless 'uname' itself comes from the cross-toolkit. Question #1: Is there any problem for MinGW64 to produce a 'uname' port that would DTRT in the first place? Question #2: If MinGW64 'uname' will not be available any time soon, is there any problem in using the --build option when you configure? As an aside, I find it surprising, to say the least, that MinGW64 GCC does not have a built-in symbol specific to it, one that could be produced by something like "cpp -dM". Instead, MinGW64 GCC seems to do everything in its power to present itself as MinGW32 GCC, even though the system headers and the libraries are subtly incompatible, enough to require #ifdef's to accommodate both. The bottom line is that one cannot write a script that distinguishes between MinGW64 GCC and MinGW32 GCC, and between a 32-bit MinGW64 build and 64-build MinGW64 build, except by compiling a C program that includes at least one MinGW header. Question #3: Any reasons not to add built-in macros in MinGW64 GCC that would allow to easily make the above distinctions? I bet this would make your patch to config.guess a whole lot simpler. A couple of specific comments about your patch. > + eval $set_cc_for_build > + sed 's/^ //' << EOF >$dummy.c > + #include <stdio.h> > + __MINGW32__ > + __MINGW64__ > + __MINGW64_VERSION_MAJOR > +EOF > + if $CC_FOR_BUILD -E $dummy.c 2>/dev/null | \ > + grep -q __MINGW32__ >/dev/null > + then > + # __MINGW32__ is not defined - this isn't MinGW at all. > + : > + else > + if $CC_FOR_BUILD -E $dummy.c 2>/dev/null | \ > + grep -q __MINGW64__ >/dev/null > + then > + # 32-bit mingw > + machine=i686 > + else > + # 64-bit mingw > + machine=x86_64 > + fi Unless I'm missing something, this doesn't distinguish between a 32-bit build and a 64-bit build when MinGW64 GCC is being used. Don't you need to test _WIN64 in addition, and only set machine to x86_64 if it is defined? > + if $CC_FOR_BUILD -E $dummy.c 2>/dev/null | \ > + grep -q __MINGW64_VERSION_MAJOR >/dev/null > + then > + # mingw.org toolchain > + echo ${machine}-pc-mingw32 > + else > + # mingw-w64 toolchain > + echo ${machine}-w64-mingw32 > + fi What's wrong with the "-pc-" part that you want to replace it with "-w64-"? The 32-binaries produced by MinGW64 can be run on 32-bit Windows platforms, right? And why do you want to keep the "mingw32" part when MinGW64 is used to build the package -- wouldn't it be better to use "mingw64" instead? HTH |