Re: [Mingw-users] Fwd: Re: Better mingw support

> 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