Fwd: Re: Better mingw support

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: Better mingw support

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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).

- -------- Original Message --------
Subject: Re: Better mingw support
Date: Fri, 29 Mar 2013 20:11:11 +1100
From: Ben Elliston <[hidden email]>
To: LRN <[hidden email]>

Hi.

> 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.
You'll need to discuss this with the MINGW project.  I do not accept
patches from non-MINGW maintainers for the MINGW entries in
config.guess.  I've done it before, and got a lot of flak.

Cheers, Ben


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRVWIlAAoJEOs4Jb6SI2Cw/ncH/3EWl1oQ1KeyyX1pn8Tsj80u
XzmPcy1pgA8ev6hyWp5+4TbV700dwinodVuoqhXFIb2I1n8yJ+Zx9D4zDBaIf+qa
hCbjmIi8P7CcQxnxvdIdztd3022DobHdysGbbRxbfJIIXZ6GUhVdEigUxGF9V+Bm
6YA7IWhjMzrPCLDxSqzLrXiEtyXbL8/FxXojqIChM0Vk1eaz1cPVIgJ2JGbjGWm0
nlIi9rUDn79+WFL222zjE9iP4sbI/Ap4KvViE8JcQ1Whg/ypsJ2395+8dHf6TpzI
X/zt+Yp7new6C3324tUUZLhKidoQhz+p7nDmERnb2x+YB3CiYbl/zNr752smNKU=
=A3fm
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

config.guess-mingw-w64.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Eli Zaretskii
> Date: Fri, 29 Mar 2013 13:43:09 +0400
> From: LRN <[hidden email]>
> Cc: Ben Elliston <[hidden email]>
>
> 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

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.03.2013 14:29, Eli Zaretskii wrote:
>
> First, you are using an MSYS/MinGW32 hosting environment to build
> MinGW64 executables.
Not true.
I'm using MSYS to host mingw-w64 compiler. I am not cross-compiling
anymore (when i did, i did have to use --build, --host and --target,
which made config.guess irrelevant, and that was expected and correct).
> Question #1: Is there any problem for MinGW64 to produce a 'uname'
> port that would DTRT in the first place?
mingw-w64 provides CRT (and, by extension, a gcc-based toolchain,
though i do rebuild it myself from scratch, so it's not that simple).
It does not do any msys development. Mingw.org does.
uname is a pure MSYS application, an interface to uname() syscall in
msys core. MSys can not, and should not be acutely aware of the
toolchain it is used with. In fact, i can swap toolchains in and out
of msys (edit /etc/fstab to point /mingw to new location, call `mount
- -a').
>
> Question #2: If MinGW64 'uname' will not be available any time
> soon, is there any problem in using the --build option when you
> configure?
I am not looking forward to be providing --build to every configure
scrip in every package for the rest of my natural life.
I started up the whole "make a native mingw-w64 compiler" affair
precisely because i just wanted to say "gcc", "./configure
- --prefix=/mingw" and "make", without pretending that i'm
cross-compiling (and without actually cross-compilin).

>
> 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.
Complain to gcc devs.

>
> 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.
Ask gcc devs.

>
> 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?
32-bit mingw gcc has __MINGW32__. 64-bit mingw gcc has __MINGW32__ and
__MINGW64__.
Note that i'm using native compilers (compilers that generate code for
the same architecture they run on; cross-compilers do not need
config.guess, AFAIU), without multilib capability (i'm still not
convinced of its usefulness). I also don't know whether an
x86_64-w64-mingw32-gcc (when compiling 32-bit code with -m32) would
define __MINGW64__ or not.

>
>> +    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?
Because it's i686-w64-mingw32-gcc.exe, not i686-pc-mingw32-gcc.exe
w64 vendor prefix identifies mingw-w64 as the origin of the toolchain.
AFAIU, w64 toolchains have features that are not available in 'pc'
toolchains (not sure if it's toolchain-build-time decision or
program-build-time decision, will have to ask; AFAIR, the difference
is in  auxiliary crt object files). So vendor string does make a
difference.

Binaries can be run anywhere, yes. Just as you can run
x86-MSVC-compiled binaries on any 32-bit Windows. Or x86-ICC-compiled.

>
> 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?
Welcome to mingw toolchains triplet naming nightmare world.
I would have preferred it to be something like x86_64-lrn-gcc-windows
or something. Had discussions about this on #mingw-w64 at oftc.net.
Changing triplets for gcc-on-windows will require changes to huge
number of packages. Maybe one day i will do something like that.

(sorry, Enigmail is going to botcher quoted fragments of the patch :( )
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRVXQaAAoJEOs4Jb6SI2Cw0cUH/1mla33zO4mybcfAAol0A8W2
zog9IPrkW98t4RovJWFxVFEnRzflSh52fSXQUCTAosYbKBnOuNiUNc5dxQR2x2aT
qLX0uI0izLDmPcYzSsHQNAzlRneqqgJgM+zMSOlzVgV1hVA+tYtsr91rYxfU9bib
bI5A6sgGH0J+QAqXySoQIiHBJpVIZda5yEOhwWEiXbMNmrVwLs5QV2iZ395DJs3q
1NEcDEZxrHw8t85Cq6x5xnFRwKVx1N9OXYiDkwKhQETOchpYsjyJodj/awkcfufJ
xQULizWn4iR6cyHXcZT0OJWjJqulhZyD0zwPQhtqJDuXiG37jm6PB4azUdZtsmY=
=Qa06
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Alexpux
>> Question #2: If MinGW64 'uname' will not be available any time
>> soon, is there any problem in using the --build option when you
>> configure?
> I am not looking forward to be providing --build to every configure
> scrip in every package for the rest of my natural life.
> I started up the whole "make a native mingw-w64 compiler" affair
> precisely because i just wanted to say "gcc", "./configure
> - --prefix=/mingw" and "make", without pretending that i'm
> cross-compiling (and without actually cross-compilin).

You can set MSYSTEM environment variable to what you want and uname return it
For example:
  export MSYSTEM=MINGW64
  uname -a
Returning MINGW64_NT-6.1

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Eli Zaretskii
In reply to this post by lrn-2
> Date: Fri, 29 Mar 2013 14:59:41 +0400
> From: LRN <[hidden email]>
>
> On 29.03.2013 14:29, Eli Zaretskii wrote:
> >
> > First, you are using an MSYS/MinGW32 hosting environment to build
> > MinGW64 executables.
> Not true.
> I'm using MSYS to host mingw-w64 compiler.

What's the difference?  My point is that the host environment and the
target environment differ.  If they didn't, then MSYS's 'uname' would
be exactly what you want.

> > Question #1: Is there any problem for MinGW64 to produce a 'uname'
> > port that would DTRT in the first place?
> mingw-w64 provides CRT (and, by extension, a gcc-based toolchain,
> though i do rebuild it myself from scratch, so it's not that simple).
> It does not do any msys development. Mingw.org does.

Welcome to Free Software, where you are on your own ;-)

No need to depend on MSYS, just produce a simple uname.exe that
displays the right string, and remove the one from MSYS from PATH.
That's it!  Or ...

> > Question #2: If MinGW64 'uname' will not be available any time
> > soon, is there any problem in using the --build option when you
> > configure?
> I am not looking forward to be providing --build to every configure
> scrip in every package for the rest of my natural life.

... put this is your config.site file:

  build_alias=x86_64-w64-mingw32

and that's it!  Every configure script loads this file from one of the
standard places (look at the beginning of configure for the list of
those places; search for CONFIG_SITE), so that's all you should need.

Or set MSYSTEM in the environment, as suggested by Алексей.

> I started up the whole "make a native mingw-w64 compiler" affair
> precisely because i just wanted to say "gcc", "./configure
> - --prefix=/mingw" and "make", without pretending that i'm
> cross-compiling (and without actually cross-compilin).

I understand, I just think that it will take years for these changes
to percolate through the channels and to the packages you build, so
you might as well use easier ways.


------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

lrn-2
In reply to this post by Alexpux
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.03.2013 15:15, Алексей Павлов wrote:

>>> Question #2: If MinGW64 'uname' will not be available any time
>>> soon, is there any problem in using the --build option when
>>> you configure?
>> I am not looking forward to be providing --build to every
>> configure scrip in every package for the rest of my natural
>> life. I started up the whole "make a native mingw-w64 compiler"
>> affair precisely because i just wanted to say "gcc",
>> "./configure - --prefix=/mingw" and "make", without pretending
>> that i'm cross-compiling (and without actually cross-compilin).
>
> You can set MSYSTEM environment variable to what you want and uname
> return it For example: export MSYSTEM=MINGW64 uname -a Returning
> MINGW64_NT-6.1
Toolchain should be usable without changes to the environment (system
or user), or changes to MSYS initialization scripts.
config.guess is perfectly capable of testing the compiler, and already
does that in some cases where uname is not enough.
Also, if MSYSTEM is user-changeable (it is), then patching
config.guess to rely on MSYSTEM is not a good decision. config.guess
should not rely on random user-defined strings to detect the system
triplet.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRVY8zAAoJEOs4Jb6SI2CwIyEH/1j61Sp7BfwV+FFMeJw5VVPX
KRPNnrhZswocY1MAHCTJ9nsJnog93axnzhCVqysYtocSuDand16iRY1zrAYSX/XU
zLJJmWts5UsW0P0xo6wir7vhxh1I5N/NbjWicCwGTZpeNneb0JOcR28pRuycg7dU
EOnq7kzzbv0uAksvVKeKq5VuTg/U55SVEj8WqjhadYf+nS8dgmG/jM5T7lQ06o6s
YjCVcOEsZ9ou4Qj+oy9CiGL8WklOu4G8RKaEbx+j5qF4e0bBWeJObJWdNHJP1zMU
uSNEf+aG+RzgWX9EaX1mBF2E5OE4olYWdSrm2T/cyNhAaRXscLgWltzmO/8bi6M=
=zea0
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Earnie Boyd
On Fri, Mar 29, 2013 at 8:55 AM, LRN wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 29.03.2013 15:15, Алексей Павлов wrote:
>>>> Question #2: If MinGW64 'uname' will not be available any time
>>>> soon, is there any problem in using the --build option when
>>>> you configure?
>>> I am not looking forward to be providing --build to every
>>> configure scrip in every package for the rest of my natural
>>> life. I started up the whole "make a native mingw-w64 compiler"
>>> affair precisely because i just wanted to say "gcc",
>>> "./configure - --prefix=/mingw" and "make", without pretending
>>> that i'm cross-compiling (and without actually cross-compilin).
>>
>> You can set MSYSTEM environment variable to what you want and uname
>> return it For example: export MSYSTEM=MINGW64 uname -a Returning
>> MINGW64_NT-6.1
> Toolchain should be usable without changes to the environment (system
> or user), or changes to MSYS initialization scripts.
> config.guess is perfectly capable of testing the compiler, and already
> does that in some cases where uname is not enough.

Caution: MSYSTEM=MINGW64 will be used for identifying
i86_64-pc-mingw64 in config.guess; I submitted a patch for it to the
maintainers of config.guess and config.sub last year.

MSYSTEM=MINGW-W64 is what this should be set to for that project!

> Also, if MSYSTEM is user-changeable (it is), then patching
> config.guess to rely on MSYSTEM is not a good decision. config.guess
> should not rely on random user-defined strings to detect the system
> triplet.

Correct!!  The correct thing would be to correct config.guess based on
the uname -s value.  Be more specific.  But also be sure you have the
most current config.guess from the repository and not one from some
package.  Currently config.guess is looking at mingw* to identify the
system.  Clearly a mingw-w64 needs some attention and care in
config.guess and config.sub.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Earnie Boyd
On Fri, Mar 29, 2013 at 9:13 AM, Earnie Boyd wrote:
>
> Caution: MSYSTEM=MINGW64 will be used for identifying
> i86_64-pc-mingw64 in config.guess; I submitted a patch for it to the
> maintainers of config.guess and config.sub last year.

Lacking the caffeine this morning s/i86_64/x86_64/

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

lrn-2
In reply to this post by Eli Zaretskii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.03.2013 15:57, Eli Zaretskii wrote:

>> Date: Fri, 29 Mar 2013 14:59:41 +0400 From: LRN
>> <[hidden email]>
>>
>> On 29.03.2013 14:29, Eli Zaretskii wrote:
>>>
>>> First, you are using an MSYS/MinGW32 hosting environment to
>>> build MinGW64 executables.
>> Not true. I'm using MSYS to host mingw-w64 compiler.
>
> What's the difference?  My point is that the host environment and
> the target environment differ.  If they didn't, then MSYS's 'uname'
> would be exactly what you want.
1) MSYS and MinGW always have 2 separate environments, by design (they
even live in different directories)
2) I suspect that you might be confusing 64-bit x86_64-w64-mingw32
(runs on 64-bit OSes only, generates 64-bit code) with 32-bit
i686-w64-mingw32 (runs on 32-bit OSes (on 64-bit ones in WoW64),
generates 32-bit code). So it's not different than stock gcc from
mingw.org, except that it's compiled by me, and with different
runtime/headers.

MSYS, in its essence, is a doppelganger. It presents a POSIXly
compatibility layer to selected few programs and to all shell scripts
(and to perl scripts via msys-perl), but the toolchain is treated as a
100% W32 program, and all libraries too. This division is not perfect,
but works 90% of the time.
This is why relying on MSYS-only uname is not a good idea - THAT part
of MSYS is geared towards POSIX compatibility.

>
>>> Question #1: Is there any problem for MinGW64 to produce a
>>> 'uname' port that would DTRT in the first place?
>> mingw-w64 provides CRT (and, by extension, a gcc-based
>> toolchain, though i do rebuild it myself from scratch, so it's
>> not that simple). It does not do any msys development. Mingw.org
>> does.
>
> Welcome to Free Software, where you are on your own ;-)
>
> No need to depend on MSYS, just produce a simple uname.exe that
> displays the right string, and remove the one from MSYS from PATH.
> That's it!
So, what should config.guess (the upstream that seeps into 99% of all
GNU packages eventually) do now? Should it continue to treat "MINGW32"
as "32-bit mingw.org-compatible gcc" (and, recently, "MINGW64" as
"64-bit mingw.org-compatible gcc")? Or maybe it should look for
LRNSCOOLCOMPILERSET in uname's output? If that is done, _i_ will have
to maintain an implementation of uname, and stick it everywhere,
otherwise MSYS+mygcc will not be usable. And if it's something
mingw-w64-specific (say, "MAXGW"), then THEY will have to maintain it.
You're also advising me to mess, by hand, with a file that package
manager installs. Usually that is something you shouldn't do yourself,
and must never suggest to a user (i usually know what i'm doing; less
experienced users often don't).

> Or ...
>
>>> Question #2: If MinGW64 'uname' will not be available any time
>>> soon, is there any problem in using the --build option when
>>> you configure?
>> I am not looking forward to be providing --build to every
>> configure scrip in every package for the rest of my natural
>> life.
>
> ... put this is your config.site file:
>
> build_alias=x86_64-w64-mingw32
>
> and that's it!  Every configure script loads this file from one of
> the standard places (look at the beginning of configure for the
> list of those places; search for CONFIG_SITE), so that's all you
> should need.
That's actually a good advice (pity i didn't get it, like, 2 years
ago...), compatible with my view of how MSYS and MinGW fit together.
Maybe we should ask config.guess maintainer to completely remove mingw
and msys bits from config.guess (since, as pointed out already,
current guess method consists of, basically, hard-coding 32-bit
mingw.org toolchain or 32-bit msys-only toolchain), and rely solely
upon config.site?

>
> Or set MSYSTEM in the environment, as suggested by Алексей.
>
>> I started up the whole "make a native mingw-w64 compiler" affair
>> precisely because i just wanted to say "gcc", "./configure -
>> --prefix=/mingw" and "make", without pretending that i'm
>> cross-compiling (and without actually cross-compilin).
>
> I understand, I just think that it will take years for these
> changes to percolate through the channels and to the packages you
> build, so you might as well use easier ways.
For me "easier ways" is to apply patches to packages locally. Because
i build them, i can patch them just fine. But any patch that i apply
locally is a patch that should have been upstream. Local patches that
are kept local - that means decreased collaboration, that the upstream
will stay flawed in some ways.
As for years it will take for changes to spread, i'm ok with
long-term-only benefits.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRVavAAAoJEOs4Jb6SI2CwiMoH/1D5HN1X0eNrj7fon0yMPIj1
LyJk9sw2KYjmGQZ6Rdx/+xSflKdXvp9GTkyQ5EsAZ2Mu7yly0sPHh0b953XDIPpG
kdtF3hWMzMS8oU+Hrfxldj17fUudE/Men2MO7oH0qA9GGTnjep4Ur2hP6vjvFAZ3
Jcv4wwfyEIYfpS52KKR5BLl97S7g3Rr9DwEi/sriniT/7NQPAsbrRoUpllw773Sl
DfWr/LVSubBXO3zHB4546hsGO2wylodWIq9zrp/lHktOX+WNER85F99P5bOMDUYZ
YCDCs03oj3y0uwu7yYHmvs00jFpQBpeAwe1QvPyJHZh+E0t28CfTiNn5ZztYGGE=
=lS1/
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

lrn-2
In reply to this post by Earnie Boyd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.03.2013 17:13, Earnie Boyd wrote:

> On Fri, Mar 29, 2013 at 8:55 AM, LRN wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 29.03.2013 15:15, Алексей Павлов wrote:
>>>>> Question #2: If MinGW64 'uname' will not be available any
>>>>> time soon, is there any problem in using the --build option
>>>>> when you configure?
>>>> I am not looking forward to be providing --build to every
>>>> configure scrip in every package for the rest of my natural
>>>> life. I started up the whole "make a native mingw-w64
>>>> compiler" affair precisely because i just wanted to say
>>>> "gcc", "./configure - --prefix=/mingw" and "make", without
>>>> pretending that i'm cross-compiling (and without actually
>>>> cross-compilin).
>>>
>>> You can set MSYSTEM environment variable to what you want and
>>> uname return it For example: export MSYSTEM=MINGW64 uname -a
>>> Returning MINGW64_NT-6.1
>> Toolchain should be usable without changes to the environment
>> (system or user), or changes to MSYS initialization scripts.
>> config.guess is perfectly capable of testing the compiler, and
>> already does that in some cases where uname is not enough.
>
> Caution: MSYSTEM=MINGW64 will be used for identifying
> i86_64-pc-mingw64 in config.guess; I submitted a patch for it to
> the maintainers of config.guess and config.sub last year.
>
> MSYSTEM=MINGW-W64 is what this should be set to for that project!
>
>> Also, if MSYSTEM is user-changeable (it is), then patching
>> config.guess to rely on MSYSTEM is not a good decision.
>> config.guess should not rely on random user-defined strings to
>> detect the system triplet.
>
> Correct!!  The correct thing would be to correct config.guess based
> on the uname -s value.
I still think that config.guess should use the toolchain to get the
info. mingw.org and mingw-w64 toolchains differ in CRT, helper object
files and headers mostly, not in msys core or uname utility (because
MSYS is a separate thing, not tied to any toolchain). CRT, helper
object files and headers are the thing where actual, tangible
difference is, and that is where config.guess should look. As i have
said already, config.guess does compile dummy programs to detect other
triplets, doing that for mingw wouldn't be unusual.

Why so much insistence on uname? Are there going to be changes in the
way uname works, have i missed some context? Right now uname depends
on MSYSTEM envvar, and MSYSTEM envvar is either user-defined, pushing
responsibility on user's shoulders, or it is hard-coded in msys.bat,
which is frozen in msys core; at best it might be able to define
MSYSTEM=MINGW64 in the future, if you ever get around to release your
own version of 64-bit toolchain. I certainly don't see msys.bat doing
mingw vs mingw-w64 detection and setting MSYSTEM accordingly, and
mingw-w64 doesn't seem interested in maintaining their own msys.bat
(or anything msys-related at all) just to have it set MSYSTEM to
"their" value.

P.S. that said, i'm not sure how this will work for cases where you
don't have CC or any other acceptable variable defined; maybe you're
not using C or C++ at all - but again, that seems to be outside of
config.guess' scope.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRVbBJAAoJEOs4Jb6SI2CwXrUIAIiNarWE5z8JynzNfQWYDIJl
mAahKEVILWiCn53Pis4A5AW5jPMy2gxiyAsYos9PH3Cfq11Gwm2OoFv+C72Umfsp
SPAuLGun7CHXUVyCD35f+FTtmSQKa5ErtzF6Y/e7y3fV3ab65a+3xJ/3jU+LfHaH
kM1eGPaCAuwuXHMaEO21Mu5Rw6fJjKJ6M5nsLYlF2UZbs/IbCXH/1pCdC6xFyO9u
JJYcTLeCPZ8sLbkEVLqjT4aLJ6tlNGI928Oy+26uhWgBiHUTWIdyqI6clTt/0SbP
EaQpNlBhMDwIi8dvdBD/+b5Bd5ZtGCdAATuCib07GUIHCG+hAsL/xPQZs1Zp9C8=
=FRW8
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Eli Zaretskii
In reply to this post by lrn-2
> Date: Fri, 29 Mar 2013 18:57:04 +0400
> From: LRN <[hidden email]>
>
> On 29.03.2013 15:57, Eli Zaretskii wrote:
> >> Date: Fri, 29 Mar 2013 14:59:41 +0400 From: LRN
> >> <[hidden email]>
> >>
> >> On 29.03.2013 14:29, Eli Zaretskii wrote:
> >>>
> >>> First, you are using an MSYS/MinGW32 hosting environment to
> >>> build MinGW64 executables.
> >> Not true. I'm using MSYS to host mingw-w64 compiler.
> >
> > What's the difference?  My point is that the host environment and
> > the target environment differ.  If they didn't, then MSYS's 'uname'
> > would be exactly what you want.
> 1) MSYS and MinGW always have 2 separate environments, by design (they
> even live in different directories)

MSYS is an environment to configure and build MinGW32 programs.  So
when you build MinGW32 programs, you use the environment natively,
because everything in these two packages fits together.  They were
created that way.  Not so when you use MinGW64 tools.

> 2) I suspect that you might be confusing 64-bit x86_64-w64-mingw32
> (runs on 64-bit OSes only, generates 64-bit code) with 32-bit
> i686-w64-mingw32 (runs on 32-bit OSes (on 64-bit ones in WoW64),
> generates 32-bit code).

No, I'm not.

> So it's not different than stock gcc from mingw.org, except that
> it's compiled by me, and with different runtime/headers.

"Different runtime/headers" _is_ the problem here.  They make the
target subtly, but significantly, different.

> > ... put this is your config.site file:
> >
> > build_alias=x86_64-w64-mingw32
> >
> > and that's it!  Every configure script loads this file from one of
> > the standard places (look at the beginning of configure for the
> > list of those places; search for CONFIG_SITE), so that's all you
> > should need.
> That's actually a good advice (pity i didn't get it, like, 2 years
> ago...), compatible with my view of how MSYS and MinGW fit together.

It's a very easy way to tailor the configure script to the needs of
the site.  You can put other variables there.  I use it sometimes to
override simplistic or wrong tests in the configure script, for
example.

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Peter Rosin
In reply to this post by lrn-2
On 2013-03-29 10:43, LRN wrote:
> + 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.
> +    :

I'm just making a note that MSYS is very capable of driving
the Microsoft compiler (CC=cl) for autoconfiscated projects,
which this patch appears to break (or at least make harder).
Please don't do that.

Cheers,
Peter


------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.03.2013 21:15, Peter Rosin wrote:

> On 2013-03-29 10:43, LRN wrote:
>> + 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. +    :
>
> I'm just making a note that MSYS is very capable of driving the
> Microsoft compiler (CC=cl) for autoconfiscated projects, which this
> patch appears to break (or at least make harder). Please don't do
> that.
>
I'm totally open to suggestions.
- From the top of my head:
A) instead of "not MinGW at all", default to
${UNAME_MACHINE}-pc-mingw32 (just like it is now) - that should
preserve the status quo.
B) do make appropriate tests for MSVC (and, while we're at it, ICC and
any other compilers still in use).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRVrFwAAoJEOs4Jb6SI2CwkAMIAJTbedShD46cCgNPmbWUolGK
bnfbk2Gn7JDB5D5cBxfQ3nkwjHmkZGBdX7fr+Fe8OW1flepK0HDiWZJFAxKrP3gL
1Y4ABZx2slPmnng9OdDySEbJXe+RPRFLBchk7R5M/zHFydsXAmzi11AJ+hxrit3f
tZ/DimrfxUlrz25zhn6jmvm5uVkZoNmHuO0Q/9gYZdhoo6sv35U4H0FC3cnYmBoG
y0KLVfPNmFkQ3XXwL4jmHjvUL8wFPNpU4O0Op9tDgiOjTbv9i5/NCuJ6ZuseAeZW
/nPH/BH0b/CkC60SbVyI7Zp3r7TvBH3Lbg/Saj4z420PyztNCnm1aQU2zVzaZwQ=
=jVxf
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Earnie Boyd
In reply to this post by lrn-2
On Fri, Mar 29, 2013 at 10:57 AM, LRN wrote:
> That's actually a good advice (pity i didn't get it, like, 2 years
> ago...), compatible with my view of how MSYS and MinGW fit together.
> Maybe we should ask config.guess maintainer to completely remove mingw
> and msys bits from config.guess (since, as pointed out already,
> current guess method consists of, basically, hard-coding 32-bit
> mingw.org toolchain or 32-bit msys-only toolchain), and rely solely
> upon config.site?

Uh, not only no, but hell no.  That will not happen!

Config.guess is just a programmed script based on the values it
receives from uname -s.  It has a maintained upstream repository that
can be adjusted.  Usually the maintainer of that script has a
difficult time in knowing exactly who and what should be adjusting a
particular piece.  However, I do watch for changes and will pitch a
hissy fit at such a change!

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Earnie Boyd
In reply to this post by lrn-2
On Fri, Mar 29, 2013 at 11:16 AM, LRN wrote:
> I still think that config.guess should use the toolchain to get the
> info. mingw.org and mingw-w64 toolchains differ in CRT, helper object
> files and headers mostly, not in msys core or uname utility (because
> MSYS is a separate thing, not tied to any toolchain). CRT, helper
> object files and headers are the thing where actual, tangible
> difference is, and that is where config.guess should look. As i have
> said already, config.guess does compile dummy programs to detect other
> triplets, doing that for mingw wouldn't be unusual.
>

The config.guess script is a POSIX script and doesn't run without a
POSIX environment!

> Why so much insistence on uname? Are there going to be changes in the

Because uname is a provided tool that works.

> way uname works, have i missed some context? Right now uname depends
> on MSYSTEM envvar, and MSYSTEM envvar is either user-defined, pushing

Actually uname doesn't care about MSYSTEM, it is the MSYS DLL that
does the work.

> responsibility on user's shoulders, or it is hard-coded in msys.bat,
> which is frozen in msys core; at best it might be able to define
> MSYSTEM=MINGW64 in the future, if you ever get around to release your
> own version of 64-bit toolchain. I certainly don't see msys.bat doing
> mingw vs mingw-w64 detection and setting MSYSTEM accordingly, and
> mingw-w64 doesn't seem interested in maintaining their own msys.bat
> (or anything msys-related at all) just to have it set MSYSTEM to
> "their" value.
>

MSYSTEM could be set in the user's environment before starting
msys.bat.  Msys.bat only sets a default if it isn't defined. That
default will be determined by the whelms of the MinGW.org project.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30.03.2013 20:55, Earnie Boyd wrote:

> On Fri, Mar 29, 2013 at 11:16 AM, LRN wrote:
>> I still think that config.guess should use the toolchain to get
>> the info. mingw.org and mingw-w64 toolchains differ in CRT,
>> helper object files and headers mostly, not in msys core or
>> uname utility (because MSYS is a separate thing, not tied to any
>> toolchain). CRT, helper object files and headers are the thing
>> where actual, tangible difference is, and that is where
>> config.guess should look. As i have said already, config.guess
>> does compile dummy programs to detect other triplets, doing that
>> for mingw wouldn't be unusual.
>>
>
> The config.guess script is a POSIX script and doesn't run without a
> POSIX environment!
Uh-oh. What's your point?

>
>> Why so much insistence on uname? Are there going to be changes
>> in the
>
> Because uname is a provided tool that works.
uname is incapable of providing relevant information. Relying on that
information is bad.

>
>> way uname works, have i missed some context? Right now uname
>> depends on MSYSTEM envvar, and MSYSTEM envvar is either
>> user-defined, pushing
>
> Actually uname doesn't care about MSYSTEM, it is the MSYS DLL that
>  does the work.
Correct. I just generalized it (uname.exe calls uname(), and uname()
is implemented in MSYS core; but from user's point of view uname
provides the info).

>
>> responsibility on user's shoulders, or it is hard-coded in
>> msys.bat, which is frozen in msys core; at best it might be able
>> to define MSYSTEM=MINGW64 in the future, if you ever get around
>> to release your own version of 64-bit toolchain. I certainly
>> don't see msys.bat doing mingw vs mingw-w64 detection and
>> setting MSYSTEM accordingly, and mingw-w64 doesn't seem
>> interested in maintaining their own msys.bat (or anything
>> msys-related at all) just to have it set MSYSTEM to "their"
>> value.
>>
>
> MSYSTEM could be set in the user's environment before starting
> msys.bat.  Msys.bat only sets a default if it isn't defined. That
> default will be determined by the whelms of the MinGW.org project.
So, basically, you're saying  "We (mingw.org) decide what default
information provided by uname is for the project we control (msys),
and other projects, which we do not control (config.guess), should use
that info to guess the triplet that basically describes the toolchain,
so that the triplet guessed by default describes our toolchain
(i686-pc-mingw32), and not the toolchain that actually is installed"?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRVyHLAAoJEOs4Jb6SI2CwYZkIAJL7NwAJ6Pc54lo6rocNs06N
JCpEr8VvN0N35Wtt8Niq0Y7pZwGT/ybIONn4vsidvMirH6houKUBWib8rhqbJe2n
kUgHTrcA0AmDk6EBk8plexCr5KcvcTGC08W/L65otFiXxOl6tTB88OUWXXcrIO9z
uYHKGsFwan1EmKrKIaOL/dczX4+R0Wz+YASnoVNCqUMLu5qe/9eeWH7XpMWOxuuw
msqzPbLXLnBHRiB+8MSzJ7Wz4jMiCTYh6dz7MMIx7YkB2Q98C2EfHmYjZGSg7hBq
YYrT9nPNHKdmK6yNNRGMoE0UK/CEYBDX6h/TKQszUZqRhcdkb3sumMhl+JtVyyM=
=dWEa
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

lrn-2
In reply to this post by lrn-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30.03.2013 13:33, LRN wrote:

> On 29.03.2013 21:15, Peter Rosin wrote:
>> On 2013-03-29 10:43, LRN wrote:
>>> + 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. +    :
>
>> I'm just making a note that MSYS is very capable of driving the
>> Microsoft compiler (CC=cl) for autoconfiscated projects, which
>> this patch appears to break (or at least make harder). Please
>> don't do that.
>
> I'm totally open to suggestions. - From the top of my head: A)
> instead of "not MinGW at all", default to
> ${UNAME_MACHINE}-pc-mingw32 (just like it is now) - that should
> preserve the status quo. B) do make appropriate tests for MSVC
> (and, while we're at it, ICC and any other compilers still in
> use).
>
Would this new version suffice? It implements my "A" suggestion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRV5svAAoJEOs4Jb6SI2CwUf8IAMQLiD78KdEuxiUUxMr9BrNM
q6XzxwL/qalxnuMB8nYpmEhlLvqWCUF/VOpMNnNbM2lBb1sdqjfSd8gap1m9rrxk
NUcnMHcGctc62r1FfZ1dG89qKLxVURvAm7rUazFwYRFhNcdtCk0sRq31BSblDtVA
/xV94wANg/Dh8cAN0GUiWHy2joFOSu5zPyNzdahp7HHWIwEvynew5K6Jr+0atr7v
jsktBw1dLN9pcWOP+SZBNe4UITBnujtRqQBg56AIHhfyzDALklQwJei8gYpjsVBv
DvbRF0M/h+DHiePH0+YBtsO/Z08G/aYb2G5K9Y4gtCGsuiizDypzPcGjm+ZT96k=
=xRBq
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

config.guess-mingw-w64-v2.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Earnie Boyd
On Sat, Mar 30, 2013 at 10:11 PM, LRN wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 30.03.2013 13:33, LRN wrote:
>> On 29.03.2013 21:15, Peter Rosin wrote:
>>> On 2013-03-29 10:43, LRN wrote:
>>>> +   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. +            :
>>
>>> I'm just making a note that MSYS is very capable of driving the
>>> Microsoft compiler (CC=cl) for autoconfiscated projects, which
>>> this patch appears to break (or at least make harder). Please
>>> don't do that.
>>
>> I'm totally open to suggestions. - From the top of my head: A)
>> instead of "not MinGW at all", default to
>> ${UNAME_MACHINE}-pc-mingw32 (just like it is now) - that should
>> preserve the status quo. B) do make appropriate tests for MSVC
>> (and, while we're at it, ICC and any other compilers still in
>> use).
>>
> Would this new version suffice? It implements my "A" suggestion.

I need to review this.  I may provide a different method.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Earnie Boyd
On Sun, Mar 31, 2013 at 1:38 PM, Earnie Boyd wrote:

> On Sat, Mar 30, 2013 at 10:11 PM, LRN wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 30.03.2013 13:33, LRN wrote:
>>> On 29.03.2013 21:15, Peter Rosin wrote:
>>>> On 2013-03-29 10:43, LRN wrote:
>>>>> +   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. +            :
>>>
>>>> I'm just making a note that MSYS is very capable of driving the
>>>> Microsoft compiler (CC=cl) for autoconfiscated projects, which
>>>> this patch appears to break (or at least make harder). Please
>>>> don't do that.
>>>
>>> I'm totally open to suggestions. - From the top of my head: A)
>>> instead of "not MinGW at all", default to
>>> ${UNAME_MACHINE}-pc-mingw32 (just like it is now) - that should
>>> preserve the status quo. B) do make appropriate tests for MSVC
>>> (and, while we're at it, ICC and any other compilers still in
>>> use).
>>>
>> Would this new version suffice? It implements my "A" suggestion.
>
> I need to review this.  I may provide a different method.
I prefer the attached method for the time being.  Eventually we will
have a 64bit version of MSYS that will allow for the proper
${UNAME_MACHINE} value of x86_64.  I'll continue to review LRN's
method, it may indeed be a better solution but I need to play with it
more.  The solution I'm giving puts more onus on the user to modify a
MSYSTEM environment variable but will work regardless.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

mingw-w64-config.guess.diff (700 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Better mingw support

Earnie Boyd
In reply to this post by lrn-2
On Sat, Mar 30, 2013 at 1:32 PM, LRN wrote:

>>
>> MSYSTEM could be set in the user's environment before starting
>> msys.bat.  Msys.bat only sets a default if it isn't defined. That
>> default will be determined by the whelms of the MinGW.org project.
> So, basically, you're saying  "We (mingw.org) decide what default
> information provided by uname is for the project we control (msys),
> and other projects, which we do not control (config.guess), should use
> that info to guess the triplet that basically describes the toolchain,
> so that the triplet guessed by default describes our toolchain
> (i686-pc-mingw32), and not the toolchain that actually is installed"?

The default value is determined by mingw.org, yes.  But I would
entertain a patch for differing %1 values than MINGW32 and MSYS such
as MINGW32-W64 and MINGW64-W64.  The icon properties could then be
used to start an environment with MSYSTEM already set without the user
needing to do so.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
123