From: Earnie B. <ea...@us...> - 2013-04-01 11:47:36
|
On Sun, Mar 31, 2013 at 9:46 PM, Ben Elliston wrote: > On Sun, Mar 31, 2013 at 02:21:00PM -0400, Earnie Boyd wrote: > >> I prefer the attached method for the time being. > > But w64 is the OS, not the machine manufacturer, right? It is actually both. The mingw-w64 project decided their triplet to be *-w64-mingw32. LRN is trying to be able to use MSYS to be able to use config.guess to give him his build environment. I designed MSYS to be flexible with the uname -s result based on environment variable MSYSTEM years ago mainly to aid the development of MSYS itself. The patch I've provided allows the user to set MSYSTEM in their environment before executing configure or globally in the Windows environment before starting MSYS. The msys.bat file could be modified to allow a parameter to set the variable and thus have the icon parameters specify the MSYSTEM value during the session startup. So MSYSTEM=MINGW64-W64 allows for x86_64-w64-mingw32 and MSYSTEM=MINGW32-W64 allows for i686-w64-mingw32. At the moment, MSYS is a 32bit executable and the system identifies itself as i686 instead of x86_64. A developer is close to being able to provide MSYS version 2 which eventually will be able to execute as a 64bit executable and that version should give the appropriate uname -m value. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: LRN <lr...@gm...> - 2013-04-01 12:17:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.04.2013 10:26, Eli Zaretskii wrote: >> 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? > > 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. 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, but by default - yes it is. Thing is, in your example you pass --build to 'configure', which prevents configure from guessing the build system type, and thus config.guess won't be called. `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). We're not talking about cross-compiling here, we're talking about the use of native toolchains, so your example is not appropriate. > > 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. I'm not sure anyone designed MSYS with multiple toolchains in mind (note that we're not talking about cross-compilers; they have prefixed names). > 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? libtool is invoked at a later stage, by that time configure already figured out what your compiler is (it uses AC_PROG_CC, usually, which does the same thing as config.guess - looks for 'gcc', 'cc', etc in PATH; it does use --host to infer the right prefix, and works correctly when cross-compiling). > > And what about all those projects that will not be using the new > config.guess for years to come? For those i will have to specify --build, --host and --target for a few years. But not for the rest of my natural life. They will get new config.guess eventually. > > 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). No, i think that the best alternative is to patch config.guess, and let configure running on MSYS guess correctly only the mingw-w64 tools and configurations; for anything else, one should simply use the "--build" argument (or provide config.site to save users some typing). (no, that wasn't serious, obviously) > > 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? The use of compiler tests in config.guess is documented. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRWXq+AAoJEOs4Jb6SI2CwXwsIAKB0wBR4uENn5pPInc/3h9Xs XxrhviBFT8ZlYyHysP3HRLO0lzFS5GvNXCs6i2eSo/ejfeOY+EcG/Jfot9Fwusg/ 5Ms3Ipbt2KLJrUtNoNudfEvRyXZRt4TBNbsTOKuM7m+C2L+fjp1BFeCdOUAFPbvR XFMY0asMdu4QR8i6tZOaq+JhAbhau2rAjSiOOWabsopXkK6r1HKqD58/1eh0YOCL CHU8ROojMNbt7exgRrAYjcQjeB0KF7hNMFYOfEob9nM+OC/iNFMmjQQB+nvUqjQr /QJL2iYrnKIqZQwGh1Oz9IYbrfzjrCz6DUr8oZgzdQriL67QGj/pDzDBHxggqNA= =qYGJ -----END PGP SIGNATURE----- |
From: Earnie B. <ea...@us...> - 2013-04-01 13:31:47
|
On Mon, Apr 1, 2013 at 8:17 AM, LRN wrote: > I'm not sure anyone designed MSYS with multiple toolchains in mind > (note that we're not talking about cross-compilers; they have prefixed > names). > Uh, yes, it was designed to execute native for MINGW32 and for MSYS. It is the reason MSYSTEM exists. It is also the reason of my proposed alternative patch to config.guess. I also stated that a compiler test may be a better solution but I will need more time to think about the outcome of that. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-04-01 13:34:50
|
> Date: Mon, 01 Apr 2013 17:00:35 +0400 > From: LRN <lr...@gm...> > > >>> 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]. Sorry, overlooked. |
From: Earnie B. <ea...@us...> - 2013-04-01 22:22:51
|
On Mon, Apr 1, 2013 at 6:03 PM, Ben Elliston wrote: > On Mon, Apr 01, 2013 at 07:47:27AM -0400, Earnie Boyd wrote: > >> It is actually both. The mingw-w64 project decided their triplet to >> be *-w64-mingw32. > > The manufacturer field is for just that. For PC-class systems where > there are numerous manufacturers of more or less identical machines, > we use "pc". If the OS is 64-bit Windows, then the OS field should be > w64. OS/2 has an overlaid environment similar to MSYS called EMX. > Their triplet is: > > echo ${UNAME_MACHINE}-pc-os2-emx > > I would have thought that for MSYS, you would have something like: > > ${UNAME_MACHINE}-pc-w64-mingw I'm only trying to provide a solution for what has already been decided by others. I'll let Kai Tietz speak to the choices of the triplet. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Kai T. <kti...@go...> - 2013-04-02 12:41:13
|
2013/4/2 Earnie Boyd schrieb: > On Mon, Apr 1, 2013 at 6:03 PM, Ben Elliston wrote: >> On Mon, Apr 01, 2013 at 07:47:27AM -0400, Earnie Boyd wrote: >> >>> It is actually both. The mingw-w64 project decided their triplet to >>> be *-w64-mingw32. >> >> The manufacturer field is for just that. For PC-class systems where >> there are numerous manufacturers of more or less identical machines, >> we use "pc". If the OS is 64-bit Windows, then the OS field should be >> w64. OS/2 has an overlaid environment similar to MSYS called EMX. >> Their triplet is: >> >> echo ${UNAME_MACHINE}-pc-os2-emx >> >> I would have thought that for MSYS, you would have something like: >> >> ${UNAME_MACHINE}-pc-w64-mingw > > I'm only trying to provide a solution for what has already been > decided by others. I'll let Kai Tietz speak to the choices of the > triplet. > > -- > Earnie The default to -pc-mingw32 is that what I prefer. The vendor-key-part w64 was just introduced to allow users to build a toolchain with additional features provided by mingw-w64 based builds. Mingw-w64 always supported also the *standard* feature-set (a triplet with any vendor-key != w64) too. Kai |
From: Earnie B. <ea...@us...> - 2013-04-02 16:38:58
|
On Tue, Apr 2, 2013 at 8:41 AM, Kai Tietz wrote: > 2013/4/2 Earnie Boyd schrieb: > >> On Mon, Apr 1, 2013 at 6:03 PM, Ben Elliston wrote: >>> On Mon, Apr 01, 2013 at 07:47:27AM -0400, Earnie Boyd wrote: >>> >>>> It is actually both. The mingw-w64 project decided their triplet to >>>> be *-w64-mingw32. >>> >>> The manufacturer field is for just that. For PC-class systems where >>> there are numerous manufacturers of more or less identical machines, >>> we use "pc". If the OS is 64-bit Windows, then the OS field should be >>> w64. OS/2 has an overlaid environment similar to MSYS called EMX. >>> Their triplet is: >>> >>> echo ${UNAME_MACHINE}-pc-os2-emx >>> >>> I would have thought that for MSYS, you would have something like: >>> >>> ${UNAME_MACHINE}-pc-w64-mingw >> >> I'm only trying to provide a solution for what has already been >> decided by others. I'll let Kai Tietz speak to the choices of the >> triplet. >> >> -- >> Earnie > > The default to -pc-mingw32 is that what I prefer. The vendor-key-part w64 > was just introduced to allow users to build a toolchain with additional > features provided by mingw-w64 based builds. Mingw-w64 always supported > also the *standard* feature-set (a triplet with any vendor-key != w64) too. Kai and I have discussed a plan privately and at this time no changes should take affect. * The user will provide the --build environment string as needed while changes take effect. * The mingw-w64 project will move from -w64-mingw32 to -pc-mingw32. * We will eventually move from -pc-mingw32 to -pc-mingw and eventually to -pc-windows. * We will clean up config.guess and config.sub as we go; the plan will take some time to incorporate throughout various products. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-04-02 17:22:12
|
> Date: Tue, 2 Apr 2013 12:38:47 -0400 > From: Earnie Boyd <ea...@us...> > Cc: Ben Elliston <bj...@ai...> > > * The mingw-w64 project will move from -w64-mingw32 to -pc-mingw32. What about the 64-bit builds? will they be x86_64-pc-mingw32? > * We will eventually move from -pc-mingw32 to -pc-mingw and eventually > to -pc-windows. I sincerely hope you won't. Gobs of projects have all kinds of quirks scattered around in order to cater to MinGW specific needs, they all rely on the canonical system id that ends with "mingw32". E.g., I've just submitted a few patches to Texinfo that are needed for the "make install" step to install a Windows manifest file for the 'install-info' program, without which you get elevation prompts each time you run the "make install" in some random GNU project which installs Info manuals. What could possibly justify breaking all that? > * We will clean up config.guess and config.sub as we go; the plan will > take some time to incorporate throughout various products. Thanks. |
From: Peter R. <pe...@ly...> - 2013-04-02 17:52:39
|
On 2013-04-02 19:22, Eli Zaretskii wrote: >> Date: Tue, 2 Apr 2013 12:38:47 -0400 >> From: Earnie Boyd <ea...@us...> >> Cc: Ben Elliston <bj...@ai...> >> >> * The mingw-w64 project will move from -w64-mingw32 to -pc-mingw32. > > What about the 64-bit builds? will they be x86_64-pc-mingw32? > >> * We will eventually move from -pc-mingw32 to -pc-mingw and eventually >> to -pc-windows. > > I sincerely hope you won't. Gobs of projects have all kinds of quirks > scattered around in order to cater to MinGW specific needs, they all > rely on the canonical system id that ends with "mingw32". E.g., I've I would have thought that looking for mingw* is much more common? (and sane for that matter) Cheers, Peter |
From: Eli Z. <el...@gn...> - 2013-04-02 17:57:21
|
> Date: Tue, 02 Apr 2013 19:52:26 +0200 > From: Peter Rosin <pe...@ly...> > CC: bj...@ai... > > > I sincerely hope you won't. Gobs of projects have all kinds of quirks > > scattered around in order to cater to MinGW specific needs, they all > > rely on the canonical system id that ends with "mingw32". E.g., I've > > I would have thought that looking for mingw* is much more common? (and > sane for that matter) I don't see why. config.guess outputs *-mingw32 for quite some time. And at least currently. MinGW64 is subtly different in its features and headers, so distinguishing between these two is still a necessity, in my experience. |
From: Peter R. <pe...@ly...> - 2013-04-02 19:10:25
|
On 2013-04-02 19:57, Eli Zaretskii wrote: >> Date: Tue, 02 Apr 2013 19:52:26 +0200 >> From: Peter Rosin <pe...@ly...> >> CC: bj...@ai... >> >>> I sincerely hope you won't. Gobs of projects have all kinds of quirks >>> scattered around in order to cater to MinGW specific needs, they all >>> rely on the canonical system id that ends with "mingw32". E.g., I've >> >> I would have thought that looking for mingw* is much more common? (and >> sane for that matter) > > I don't see why. Maybe because I "grew up" with libtool where it's the common practice? I don't know... Oh right, there's the horribly named cross-compilers following the *-mingw32msvc convention speaking for at least some kind of wildcard. > config.guess outputs *-mingw32 for quite some time. > And at least currently. MinGW64 is subtly different in its features > and headers, so distinguishing between these two is still a necessity, > in my experience. Why not sweep the common stuff with mingw* and differentiate when needed? I don't think libtool has any special code for 64-bit mingw. Cheers, Peter |
From: Eli Z. <el...@gn...> - 2013-04-02 19:17:17
|
> Date: Tue, 02 Apr 2013 21:10:14 +0200 > From: Peter Rosin <pe...@ly...> > CC: min...@li..., bj...@ai... > > > config.guess outputs *-mingw32 for quite some time. > > And at least currently. MinGW64 is subtly different in its features > > and headers, so distinguishing between these two is still a necessity, > > in my experience. > > Why not sweep the common stuff with mingw* and differentiate when > needed? How can you differentiate, when they both will be *-pc-windows? > I don't think libtool has any special code for 64-bit mingw. Maybe the differences don't matter for libtool. Or maybe no one has yet bumped into differences that do. Who knows? MinGW64 is much younger than MinGW32, we need to wait and see. |
From: niXman <i.n...@gm...> - 2013-04-02 19:26:43
|
Hi, Why, instead of two projects, not to leave only one(mingw-w64)? -- Regards, niXman ___________________________________________________ Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___________________________________________________ Another online IDE: http://liveworkspace.org/ |
From: Peter R. <pe...@ly...> - 2013-04-03 10:46:53
|
On 2013-04-02 21:17, Eli Zaretskii wrote: >> Date: Tue, 02 Apr 2013 21:10:14 +0200 >> From: Peter Rosin <pe...@ly...> >> CC: min...@li..., bj...@ai... >> >>> config.guess outputs *-mingw32 for quite some time. >>> And at least currently. MinGW64 is subtly different in its features >>> and headers, so distinguishing between these two is still a necessity, >>> in my experience. >> >> Why not sweep the common stuff with mingw* and differentiate when >> needed? > > How can you differentiate, when they both will be *-pc-windows? Maybe the way you normally differentiate between slightly different systems, namely a feature check? Let's take one difference between MinGW and MinGW64 that I know about: MinGW doesn't provide ddraw.h. So, which is better, to refuse to compile stuff that depends on ddraw.h when using MinGW, or to check if ddraw.h is there/works and go for it? I'd say that it is MUCH better to do the feature check, because then it will start working on MinGW once MinGW provides ddraw.h, and if you need to you can point to some variant of ddraw.h (that may not qualify for inclusion for MinGW license reasons) that you have on file somewhere and it'll work w/o patching the project. >> I don't think libtool has any special code for 64-bit mingw. > > Maybe the differences don't matter for libtool. Or maybe no one has > yet bumped into differences that do. Who knows? MinGW64 is much > younger than MinGW32, we need to wait and see. Maybe, or that's the norm, and you will not generally need to differentiate? Cheers, Peter |
From: Eli Z. <el...@gn...> - 2013-04-03 15:22:51
|
> Date: Wed, 03 Apr 2013 12:46:43 +0200 > From: Peter Rosin <pe...@ly...> > CC: min...@li..., bj...@ai... > > On 2013-04-02 21:17, Eli Zaretskii wrote: > >> Date: Tue, 02 Apr 2013 21:10:14 +0200 > >> From: Peter Rosin <pe...@ly...> > >> CC: min...@li..., bj...@ai... > >> > >>> config.guess outputs *-mingw32 for quite some time. > >>> And at least currently. MinGW64 is subtly different in its features > >>> and headers, so distinguishing between these two is still a necessity, > >>> in my experience. > >> > >> Why not sweep the common stuff with mingw* and differentiate when > >> needed? > > > > How can you differentiate, when they both will be *-pc-windows? > > Maybe the way you normally differentiate between slightly different > systems, namely a feature check? Let's take one difference between > MinGW and MinGW64 that I know about: MinGW doesn't provide ddraw.h. > So, which is better, to refuse to compile stuff that depends on > ddraw.h when using MinGW, or to check if ddraw.h is there/works and > go for it? That's the easy case -- testing for a header is, of course, the preferred way. I was talking about much subtler differences: functions that exist in both packages, but provide slightly different functionality. Differentiating between those by writing a test is too much trouble for no gain, and will hamper cross-compilation if nothing else. > Maybe, or that's the norm, and you will not generally need to > differentiate? I wish that were true, but it isn't. |
From: Earnie B. <ea...@us...> - 2013-04-03 16:51:35
|
On Wed, Apr 3, 2013 at 11:23 AM, Eli Zaretskii wrote: >> Date: Wed, 03 Apr 2013 12:46:43 +0200 >> From: Peter Rosin >> CC: min...@li..., bj...@ai... >> >> On 2013-04-02 21:17, Eli Zaretskii wrote: >> >> Date: Tue, 02 Apr 2013 21:10:14 +0200 >> >> From: Peter Rosin <pe...@ly...> >> >> CC: min...@li..., bj...@ai... >> >> >> >>> config.guess outputs *-mingw32 for quite some time. >> >>> And at least currently. MinGW64 is subtly different in its features >> >>> and headers, so distinguishing between these two is still a necessity, >> >>> in my experience. >> >> >> >> Why not sweep the common stuff with mingw* and differentiate when >> >> needed? >> > >> > How can you differentiate, when they both will be *-pc-windows? >> >> Maybe the way you normally differentiate between slightly different >> systems, namely a feature check? Let's take one difference between >> MinGW and MinGW64 that I know about: MinGW doesn't provide ddraw.h. >> So, which is better, to refuse to compile stuff that depends on >> ddraw.h when using MinGW, or to check if ddraw.h is there/works and >> go for it? > > That's the easy case -- testing for a header is, of course, the > preferred way. I was talking about much subtler differences: > functions that exist in both packages, but provide slightly different > functionality. Differentiating between those by writing a test is too > much trouble for no gain, and will hamper cross-compilation if nothing > else. > I would use known vendor macro's to determine which is which. Something like #ifdef __MINGW64_VERSION_STR #define MINGW_ABI V2 #else #define MINGW_ABI V1 #endif -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-04-03 16:56:35
|
> Date: Wed, 3 Apr 2013 12:51:27 -0400 > From: Earnie Boyd <ea...@us...> > > I would use known vendor macro's to determine which is which. Something like > > #ifdef __MINGW64_VERSION_STR > #define MINGW_ABI V2 > #else > #define MINGW_ABI V1 > #endif Alas, __MINGW64_VERSION_STR is not defined, until you include _mingw.h. |