On Sat, 23 Apr 2011 16:38:57 +0200, Adam Borowski <kilob...@angband.pl> wrote: > On Sat, Apr 23, 2011 at 05:05:33AM -0500, Jonathan Nieder wrote: > > IIUC then the GNU triplet includes the choice of C library because > > binaries (e.g., libraries) compiled against mingw32 and mingw-w64 > > cannot be linked (i.e., they do not share ABI). Though I could easily > > be wrong. > > Note that the triplets used by mingw-w64 were carefully chosen to produce as > much confusion as possible. The two architectures: win32 and win64 have > both "w32" and "w64" in the name: > * i686-w64-mingw32 > * x86_64-w64-mingw32
“were carefully chosen” is perhaps a slight exaggeration (see http://bugs.debian.org/622276 for my understanding of how these triplets ended up being used), but I do admit it can be confusing. > The former is ABI-compatible not only with i586-mingw32msvc but also with > real msvc. I just tried all combinations of these three, even including > malloc()ing from an object compiled with one and free()ing from another. > > Everything seems to work fine [1]. I can confirm this too, as far as I've been able to determine the output of gcc-mingw32 in Debian is compatible with that of gcc-mingw-w64 when targeting Win32. > This is for C. C++ between MSVC10 and mingw32 is not ABI-compatible, but > even gcc breaks compatibility there completely every a few releases > (remember -c102 in gcc-4.0?) and in minor points more often. So does MSVC. > Our two mingw32 versions seem to be compatible with each other, though. I haven't checked this but I'll take your word for it. > > IIRC according to the multiarch spec, paths in Debian use "simplified" > > triplets (DEB_HOST_MULTIARCH) with i[3456...]86 replaced by i386. > > Including so much unnecessary detail about the default instruction set > > in the triplet is unusual (I know of no example other than x86). As > > you mention, in the ix86 case it causes problems so we work around it. > > Distinguishing between two ABI-compatible compilers would be even worse. > Fortunately, nothing started using these names yet, so it's a perfect moment > to discuss a common arch name. > > Currently, the following packages use i586-mingw32msvc: > * gcc-mingw32 > * mingw32 > * mingw32-binutils > * mingw32-ocaml > * mingw32-runtime > * nsis I'm hoping the mingw-w64 set of packages (mingw-w64, binutils-mingw-w64 and gcc-mingw-w64) will be good enough to replace gcc-mingw32, mingw32, mingw32-binutils and mingw32-runtime. I originally started working on mingw-w64 to get wine-gecko into the archive and thus allow wine packaging to resume, but it seemed to me a good time as well to work on cleaning up the whole set of mingw packages in Debian. I've sent patches to allow most of the reverse-build-dependencies of mingw32 or gcc-mingw32 to build using mingw-w64 (nsis, autorun4linuxcd, cpio, gzip, gnupg and win32-loader so far), and I'm working on the remaining two (mingw32-ocaml and libreoffice). Completing all this would mean the i586-mingw32msvc target could be forgotten entirely; no one outside Debian uses it (any more), upstream and others have switched to the -w64-mingw32 suffix. (See also http://bugs.debian.org/606825 for extensive discussion and a first patch for dpkg support.) > There's no need to use the same triplet for multiarch as for compiler, > so the new path might use something else. I don't care what, as long as > it's consistent between all of win32 in Debian. That's fine by me, regardless of whether mingw-w64 ends up being “all of win32 in Debian” or not! Regards, Stephen
signature.asc
Description: PGP signature
