Hi, As you may know I'm trying to get full-blown MinGW-w64 support in Debian. The last big hurdle there that's not Debian-specific is the triplets used by MinGW-w64, and with the ARM target getting ready it seems now would be a good time to discuss this.
You can find all the details of the Debian discussion on https://bugs.debian.org/606825; to cut a long story short, the general idea is that "<cpu>-w64-mingw32" should be handled in a fashion similar to the ARM triplets, with "w64-mingw32" being the OS part, leaving a vendor to be filled in, presumably as "pc" or "unknown" (depending on whether PC-style or ARM-style is preferred). On ARM for example the typical "arm-linux-gnueabihf" triplet actually maps to "arm-unknown-linux-gnueabihf" in the toolchain. Doing this would allow config.sub to know about w64-mingw32 (without merging it with mingw32), marking it as a separate ABI (which it sort-of is in effect already, isn't it?). It would still allow people to use the well-known i686-w64-mingw32 and x86_64-w64-mingw32 triplets, even down to the cross-compilation paths (I have a version of gcc which does this), but they would be handled internally in the toolchain as i686-pc-w64-mingw32 and x86_64-pc-w64-mingw32. ARM would then be armv7-unknown-w64-mingw32. Getting there involves patching gcc and libtool, re-libtoolizing affected source packages, adding the triplet to config.sub (and config.guess) and that's pretty much it I think... Or more radically we could just go for w64-mingw, and drop the "32" suffix entirely; this is similar to what is suggested on https://www.winehq.org/wwn/369 for the ARM target. With some config.sub support we could have the widely used triplets mapped to i686-pc-w64-mingw and x86_64-pc-w64-mingw. What do you think? I don't mind doing the work getting patches upstream, but I would like to make sure I'm not doing something silly or that people in the MinGW-w64 project disagree with. Another suggestion in the Debian bug report was to use the mingw64 triplet which is already available in config.sub, but which I believe is intended for use by MinGW, not MinGW-w64. How would that fly? Regards, Stephen
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
