From: LRN <lr...@gm...> - 2013-03-29 09:43:41
Attachments:
config.guess-mingw-w64.patch
|
-----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 <bj...@ai...> To: LRN <lr...@gm...> 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----- |
From: Алексей П. <al...@gm...> - 2013-03-29 11:15:14
|
>> 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 |
From: Eli Z. <el...@gn...> - 2013-03-29 11:57:03
|
> Date: Fri, 29 Mar 2013 14:59:41 +0400 > From: LRN <lr...@gm...> > > 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. |
From: Earnie B. <ea...@us...> - 2013-03-29 13:13:46
|
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 |
From: Earnie B. <ea...@us...> - 2013-03-29 13:18:08
|
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 |
From: Earnie B. <ea...@us...> - 2013-03-30 16:55:47
|
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 |
From: Earnie B. <ea...@us...> - 2013-03-31 18:25:03
|
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 |
From: LRN <lr...@gm...> - 2013-03-31 20:30:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31.03.2013 22:24, Earnie Boyd wrote: > 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. > I can see how that would work, but that places the burden of providing appropriate shortcuts to msys.bat either to mingw.org (which is highly suboptimal - why should you maintain shortcuts for toolchains made by other projects, especially since mingw-get can't install them?) or mingw-w64 (which means some kind of installer or somesuch, which only purpose is to create shortcuts for msys with %1 set to MINGW32-W64 or MINGW64-W64). That - instead of just doing appropriate checks in config.guess itself. So far i haven't heard how this: [shortcut -> msys.bat -> MSYSTEM -> msys-1.0.dll uname () -> uname.exe - -> config.guess] scheme, which: * requires maintenance * requires synchronization - you have to make sure that %1 in the shortcut matches the toolchain mapped to /mingw in /etc/fstab - you can no longer switch a MSYS installation from one toolchain to another) * requires msys.bat patching AND config.guess patching at the same time (both need to recognize new MSYSTEM values) is better than a much simpler: [$CC_FOR_BUILD -> config.guess] way, which: * can support any toolchain by just patching config.guess * always reports correct triplet for any known toolchain, regardless of how MSYS is configured * is maintained by a 3rd party that is actually interested in maintaining it. I'd say that the second way is less complex, difficult to break, and increases toolchain independence from MSYS. Which is all good. What advantages does your way bring to the table? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRWJzIAAoJEOs4Jb6SI2Cwc7UIALZ0UpxgHNQg7EJzP/LZYPfn AAW+1w78jVoXIOvNNrQepvW4LFJDkHCNPybsDP+XBckX7h9hxbUys/lQdT/dTnKp x7XK25AnYIVKC2kzErlCl49E9G3kAochzEEHvQkRrZHykv4fTzPxiQcWGB3hC/P9 pMIsy/XYGEm2XOWbwgcthCVXwqZcu1zGFHVtT689EPeinHHhjBaayhKBR8QqSfIm fTxsrGL7BxOXsmDj2wEvwkfdIiFW/77aXwFqDc1sAywXtToHGrwNGXau+UdGCUNS VVkofZ8D6l1aeiQemPIunDxDYhonb6nBgdLv6iT7SFtvN6VaJIdDLljAuPtih30= =ifK9 -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2013-04-01 06:26:13
|
> Date: Mon, 01 Apr 2013 00:30:00 +0400 > From: LRN <lr...@gm...> > > So far i haven't heard how this: > [shortcut -> msys.bat -> MSYSTEM -> msys-1.0.dll uname () -> uname.exe > - -> config.guess] > scheme, which: > * requires maintenance > * requires synchronization - you have to make sure that %1 in the > shortcut matches the toolchain mapped to /mingw in /etc/fstab - you > can no longer switch a MSYS installation from one toolchain to another) > * requires msys.bat patching AND config.guess patching at the same > time (both need to recognize new MSYSTEM values) > > is better than a much simpler: > [$CC_FOR_BUILD -> config.guess] > way, which: > * can support any toolchain by just patching config.guess > * always reports correct triplet for any known toolchain, regardless > of how MSYS is configured > * is maintained by a 3rd party that is actually interested in > maintaining it. > > I'd say that the second way is less complex, difficult to break, and > increases toolchain independence from MSYS. Which is all good. What > advantages does your way bring to the table? Caveat: I do not speak for the MinGW or MSYS projects. That said, the proposed scheme looks backwards to me. If you read the Autoconf documentation, you will clearly see that specifying the host and the target of the build is primary, and determining the build tools, including the compiler, is secondary. E.g., if you say ./configure --build=i686-pc-linux-gnu --host=m68k-coff then configure will display a warning if "gcc" is invoked as the compiler, as opposed to "m68k-coff-gcc" that is expected. (See the node "Specifying Target Triplets" in the Autoconf manual.) What you propose does the exact opposite: it infers the build type from the first compiler found on PATH. By the way, neither of the proposed schemes caters to a possibility that I have more than a single toolchain installed (under different names), at least not easily. Tweaking environment variables (MSYSTEM) is not something any J.R. Hacker will easily discover, and likewise tweaking PATH to have the "right" tools first. By contrast, using "--build" is well documented and known to anyone who ever ran a configure script. It is also well supported by the entire toolchain; e.g., are you sure that if the configure script invokes libtool, the latter will still recognize your build type correctly? And what about all those projects that will not be using the new config.guess for years to come? So I still think that the best alternative is to leave config.guess alone, and let configure running on MSYS guess correctly only the mingw.org tools and configurations; for anything else, one should simply use the "--build" argument (or provide config.site to save users some typing). If there ever will be an MSYS-W64 that supports MinGW64 out of the box as its "native" environment, then it should guess MinGW64, and let other builds use "--build". IOW, why look for complicated undocumented solutions, when a simple and documented one already exists? |
From: Eli Z. <el...@gn...> - 2013-04-01 12:30:35
|
> Date: Mon, 01 Apr 2013 16:17:02 +0400 > From: LRN <lr...@gm...> > > > ./configure --build=i686-pc-linux-gnu --host=m68k-coff > > > > then configure will display a warning if "gcc" is invoked as the > > compiler, as opposed to "m68k-coff-gcc" that is expected. (See > > the node "Specifying Target Triplets" in the Autoconf manual.) > > What you propose does the exact opposite: it infers the build type > > from the first compiler found on PATH. > Well, you can set CC (or CC_FOR_BUILD, or HOST_CC) before invoking > 'configure', so it's not necessarily the first compiler found on PATH, Setting CC is discouraged by autoconf.info: Note that if you do not specify `--host', `configure' fails if it can't run the code generated by the specified compiler. For example, configuring as follows fails: ./configure CC=m68k-coff-gcc You can only get away with that because MinGW64 tools _can_ be run on Windows. IOW, specifying CC is not for overriding the architecture, it is for using, say, a different version of GCC, as in "CC=gcc-4.8.10" used to try an experimental or an old version of the compiler. > `man config.guess' states that it will guess build system triplet from > a native compiler (i.e. first non-prefixed compiler it finds from the > list of 'cc', 'gcc', etc), and advises you to set CC_FOR_BUILD > manually in case you're cross-compiling (i.e. in case CC is set and > it's a cross-compiler for host, not a native compiler). config.guess uses uname to guess, and CC_FOR_BUILD just to fine-tune the guess in some corner cases. If you think setting CC_FOR_BUILD is the way to fine-tune guessing the MinGW environment, why didn't you propose a patch along those lines? > > IOW, why look for complicated undocumented solutions, when a > > simple and documented one already exists? > The use of compiler tests in config.guess is documented. But you didn't use CC_FOR_BUILD in your patch. |
From: LRN <lr...@gm...> - 2013-04-01 13:01:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.04.2013 16:30, Eli Zaretskii wrote: >> Date: Mon, 01 Apr 2013 16:17:02 +0400 From: LRN >> <lr...@gm...> >> >>> ./configure --build=i686-pc-linux-gnu --host=m68k-coff >>> >>> then configure will display a warning if "gcc" is invoked as >>> the compiler, as opposed to "m68k-coff-gcc" that is expected. >>> (See the node "Specifying Target Triplets" in the Autoconf >>> manual.) What you propose does the exact opposite: it infers >>> the build type from the first compiler found on PATH. >> Well, you can set CC (or CC_FOR_BUILD, or HOST_CC) before >> invoking 'configure', so it's not necessarily the first compiler >> found on PATH, > > Setting CC is discouraged by autoconf.info: > > Note that if you do not specify `--host', `configure' fails if it > can't run the code generated by the specified compiler. For > example, configuring as follows fails: > > ./configure CC=m68k-coff-gcc > > You can only get away with that because MinGW64 tools _can_ be run > on Windows. IOW, specifying CC is not for overriding the > architecture, it is for using, say, a different version of GCC, as > in "CC=gcc-4.8.10" used to try an experimental or an old version of > the compiler. Yes, that's why CC_FOR_BUILD is preferable, if you want to influence config.guess. CC is set from, for example, --host, so it could be a cross-compiler. Also note that while configure will autodetect CC (from --host, if provided), it will do so _after_ running config.guess. I'd like to stress (again) that cross-compiling is a different beast, and usually user must explicitly state at least --host (sometimes - --target; --build or CC_FOR_BUILD are needed if user also sets CC before running configure) when cross-compiling. > >> `man config.guess' states that it will guess build system triplet >> from a native compiler (i.e. first non-prefixed compiler it finds >> from the list of 'cc', 'gcc', etc), and advises you to set >> CC_FOR_BUILD manually in case you're cross-compiling (i.e. in >> case CC is set and it's a cross-compiler for host, not a native >> compiler). > > config.guess uses uname to guess, and CC_FOR_BUILD just to > fine-tune the guess in some corner cases. Yes, again, i glossed over that (assuming that everyone knows it already). config.guess does use uname, then fine-tunes the result with CC (when the values reported by uname are ambiguous - exactly our case). > > If you think setting CC_FOR_BUILD is the way to fine-tune guessing > the MinGW environment, why didn't you propose a patch along those > lines? My patch works exactly along these lines. It assumes that MINGW32 in uname means "MSYS in MinGW mode", and proceeds to use CC_FOR_BUILD to get build system triplet. CC_FOR_BUILD is set by `set_cc_for_build' function in config.guess, which sets it (if it is not set before that) from CC or CC_HOST or (if these are unset) from the first compiler found in PATH. It does ignore the recently-added "MINGW64" case, because i honestly have no idea what it means (currently MSYS will not define MSYSTEM=MINGW64), and had no way to test any modifications to it. Does it mean "64-bit MSYS in MINGW mode"? Does it mean "32-bit MSYS in MINGW64 mode"? I don't know. I refused the temptation to guess. > >>> IOW, why look for complicated undocumented solutions, when a >>> simple and documented one already exists? >> The use of compiler tests in config.guess is documented. > > But you didn't use CC_FOR_BUILD in your patch. I do. Have you been looking at the wrong patch, mayhaps? I'm speaking of [1], attached to the first message in [2]. [1] http://mingw.5.n7.nabble.com/attachment/31098/0/config.guess-mingw-w64.patch [2] http://mingw.5.n7.nabble.com/Fwd-Re-Better-mingw-support-td31098.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRWYTzAAoJEOs4Jb6SI2CwB+AH/ReBWjNTd+xSf9KSgZ32X+kT B/3nnS33Bq3WEO3XqyhqqPlLlqGr5j5pa/qPyVN/kpCauZhZrG5G7GN64traXOEU LpeyOmQ/uqbZJUCFc5jZMpz/Abgh/yCl09a1SrfF6uaqLhm3FRbhDL07VuzmShyG TKhUmsPcYEFGO3cWGKuXp9ERrhPUXMh9xvvVtzvoje/CvvWvviY4lprrSWCbqkw4 aF+IQjsU0x7m2YJcSb1LALOmqYqHtFBURL0qra6ALCsdzW4vbPG7gciGRojEEyf4 E1yeA1NwFyjE+z7HSH72c9xL/7eY0Qf8eVvYYwDK76MbHJwV3Q45piOKmkpuQ6A= =4JDJ -----END PGP SIGNATURE----- |
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 |
From: LRN <lr...@gm...> - 2013-03-29 11:00:01
|
-----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----- |
From: LRN <lr...@gm...> - 2013-03-29 12:55:37
|
-----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----- |
From: LRN <lr...@gm...> - 2013-03-29 14:57:26
|
-----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 >> <lr...@gm...> >> >> 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----- |
From: Earnie B. <ea...@us...> - 2013-03-30 16:39:41
|
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 |
From: LRN <lr...@gm...> - 2013-03-29 15:16:46
|
-----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----- |
From: Eli Z. <el...@gn...> - 2013-03-29 15:42:12
|
> Date: Fri, 29 Mar 2013 18:57:04 +0400 > From: LRN <lr...@gm...> > > On 29.03.2013 15:57, Eli Zaretskii wrote: > >> Date: Fri, 29 Mar 2013 14:59:41 +0400 From: LRN > >> <lr...@gm...> > >> > >> 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. |
From: Peter R. <pe...@ly...> - 2013-03-29 17:15:47
|
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 |
From: LRN <lr...@gm...> - 2013-03-30 09:33:59
|
-----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----- |
From: LRN <lr...@gm...> - 2013-03-30 17:33:20
|
-----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----- |
From: LRN <lr...@gm...> - 2013-03-31 02:11:21
Attachments:
config.guess-mingw-w64-v2.patch
|
-----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----- |
From: Earnie B. <ea...@us...> - 2013-03-31 17:38:21
|
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 |
From: Earnie B. <ea...@us...> - 2013-03-31 18:21:11
Attachments:
mingw-w64-config.guess.diff
|
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 |
From: Keith M. <kei...@us...> - 2013-04-15 17:33:29
|
I know it's been two or three weeks now ... I didn't want to become embroiled in this discussion; it is a distraction from more pressing issues. However, as MinGW.org project co-administrator, I feel obliged to at least record that I am strongly opposed to the patch philosophy expounded by the OP; see below... On 31/03/13 19:21, Earnie Boyd wrote: > On Sun, Mar 31, 2013 at 1:38 PM, Earnie Boyd wrote: >> On Sat, Mar 30, 2013 at 10:11 PM, LRN wrote: >>> 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. So do I. > Eventually we will have a 64bit version of MSYS that will allow for > the proper ${UNAME_MACHINE} value of x86_64. This is actually the crux of the issue; regardless of whether MSYS is 32-bit or 64-bit, should `uname -m' not report `x86_64' when running on a 64-bit processor, rather than `i686'? Do we really need to wait for 64-bit MSYS, to correct this anomaly? > I'll continue to review LRN's method, it may indeed be a better > solution but I need to play with it more. It is LRN's method to which I am opposed. See, AIUI config.guess isn't about identifying tool chains; it is about identifying the $build_alias for the *platform*, on which the tool chain is running. Regardless of any delusion which LRN may wish to embrace, technically he *is* cross compiling [*]; (`uname -m' is reporting a $build_alias relating to an `i686' platform, whereas he wants to have a $host_alias relating to an `x86_64' platform, and `$build_alias != $host_alias' is the determinant for cross compiling). Now, LRN may well have a legitimate expectation that, when he runs `uname -m' on his 64-bit platform, it *should* report `x86_64'; that it actually reports `i686' is a bug in MSYS uname, (and that's where it should be fixed). It isn't appropriate to kludge around this bug, by gerrymandering a deeply invasive patch within config.guess > The solution I'm giving puts more onus on the user to modify a > MSYSTEM environment variable but will work regardless. IMO, it's still more of a kludge than a solution, but it's a less invasive kludge, and therefore preferable as an interim work around. Do note, however, that while changing $MSYSTEM may influence the output of `uname -s', it has no effect on the anomalous output of `uname -m'. [*] By LRN's reasoning, on this platform: $ uname -a Linux ... 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux $ which mingw32-gcc /home/keith/mingw32/bin/mingw32-gcc I could: $ for f in /home/keith/mingw32/bin/mingw32-*; do > ln $f `echo $f | sed 's!mingw32-!!'`; > done $ PATH="/home/keith/mingw32/bin:$PATH" and claim that *I* am *not* cross compiling, when I compile code for ultimate deployment on a Win32 host. I hope we can all agree that this would be a stretch of credulity too far, yet it is an *exact* analogue for LRN's assertion. -- Regards, Keith. |