On Thu, Jul 29, 2010 at 11:04 AM, Earnie <[email protected]> wrote: > Luis Lavena wrote: >> On Wed, Jul 28, 2010 at 1:54 PM, Earnie >> <[email protected]> wrote: >> The suggested target triplet for 64bits is x86_64-pc-mingw32 >> >> Notice the "pc" part, which indicates vendor "pc" (mingw.org) vs. >> w64 (mingw-w64 project). >> > > Yes, as I said misinformation abounds.
We switched to using the vendor part of the triplet after that document was written. The vendor portion is now very important to distinguish what we do here from what mingw.org does. I agree that the choice of moniker blows, but it is what it is. >> I undestand that 64, w64 and mingw32 all in one sentence can confuse >> users (indeed it confuses me), but I believe is less confusing than >> running: > > The original project is MinGW, no 32. It was named such so that when 64 > bit Windows was developed it would create *-*-mingw64 to imply a 64 bit > Windows ABI. The *-*-mingw32 is meant only to imply 32 bit Windows ABI > as provided by the MinGW project. mingw64 is inappropriate, as Win64 and Win32 are too closely intertwined. This is not like Win16 vs Win32. There's a lot of information readily available on why we chose to not make it mingw64 instead of mingw32. That said, I agree that just plain "mingw" is better. Although really, it should even be simplified to just plain "windows". As in, x86_64-w64-windows. But that's a perfect world where all bike sheds are blue (I like blue). >> >> sh -c "./config.guess" >> >> and getting the completely wrong platform. >> >> If supplying MSYSTEM=MINGW32-W64 can target i686-w64-mingw32 and >> MSYS=MINGW64 can target x86_x64-w64-mingw32, I believe one less >> error-prone and WTF moment could been eliminated. >> > > This is just wrong. *-*-mingw32 implies a target of 32 bit Windows ABI > so MSYSTEM=MINGW32-W64 is meaningless. I also think it is wrong to > introduce i686-w64-mingw32 as a triplet, it should remain > i686-pc-mingw32 regardless of which project is producing the binaries. Before you make this statement, you need to fully understand just what the distinctions are between a -pc- vendor and a -w64- vendor. What we supply for compiling on Win32 is different from what mingw.org supplies, and the vendor tag is necessary for gcc to understand the difference. GCC behaves differently when you use our vendor tag with our product instead of the generic vendor tag with another product. >> I appreciate all your comments. I can create a patch upstream for >> this if we agree on the outcome. > > Thanks for the offer for upstream patching but let's make sure everyone > agrees before patching anything. > > IMO, there should be only two triplets to identify MinGW (where MinGW is > a reference to both projects). The first part of the triplet identifies > the CPU and for Windows that will be either i?86 or x86_64 and is > derived from ``uname -m''. The second part of the triplet identifies > the processor ``uname -p'' which MSYS uname gives unknown but > config.guess/config.sub can modified to the more commonly know *-pc-*. > The third part of the triplet gives the kernel (or runtime) name ``uname > -s'' and for MSYS this is where MSYSTEM comes into play. Given this my > opinion is that we should only have i[3456]86-pc-mingw32 and > x86_x64-pc-mingw64. Feel free to express your opinions. Again, the vendor tag is extremely important, and it cannot go away at this time. There are 3 viable triplets for a reason: x86_64-w64-mingw* i686-w64-mingw* i686-pc-mingw* At least for now, it has to stay that way. ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
