[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

On Sat, 23 Apr 2011 16:38:57 +0200, Adam Borowski <kilobyte@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!



Attachment: signature.asc
Description: PGP signature

Reply to: