On Sat, Apr 23, 2011 at 05:05:33AM -0500, Jonathan Nieder wrote: > Hi, > > Adam Borowski wrote: > > > Such dirs cannot include the compiler's name, since there are multiple > > compilers for the architecture. Binaries compiled with > > i586-mingw32msvc-gcc, i686-w64-mingw32-gcc and MSVC share the same ABI. > > > > Even specific models of CPUs are no good: on i386, gcc -dumpmachine returns > > i486-linux-gnu yet the arch triplet is i386-linux-gnu. > > 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 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]. 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. > 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 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. [1]. Googling around, I see there's a problem with bitfields in structures which has been fixed only in gcc-4.6, so it's "almost fine". It seems that MSVC ABI compatibility is one of goals for mingw. Anyway, it's not like Debian can ship anything compiled with real MSVC, so if you think that "almost compatible" is not good enough, the triplet can include -mingw rather than -msvc. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice.
Attachment:
signature.asc
Description: Digital signature