Hi, On Mon, 13 Aug 2012 09:10:55 -0700, Jonathan Nieder <jrnie...@gmail.com> wrote: > Guillem Jover wrote: > > The main issue I have with this request is that the upstream triplet just > > seems wrong, as it encodes part of the ABI in the vendor field. That's > > AFAIR, from reading the thread back then. > > > > For dpkg tools the vendor is irrelevant, and having to take it into > > account would imply changing the underlaying infrastructure which > > might not be a problem per se, if the reason for requiring this wan't > > wrong. > > I'm inclined to agree that something like i386-windows-mingw_w64 or > i386-mingw32-w64, to more closely parallel i386-linux-gnu, would be > nicer. > > For reference for forgetful people like me: the tuple used in the wild > is i686-w64-mingw32. That could mean a multiarch triplet of > i386-w64-mingw32. (Anything except the Debian arch name and multiarch > triplet can be easily changed later without rebuilding many packages > and is thus not something to worry about much yet.) > > gcc/doc/install.texi advertises: > > GCC contains support for x86-64 using the mingw-w64 > runtime library, available from http://mingw-w64.sourceforge.net/. > This library should be used with the target triple x86_64-pc-mingw32. > > That's out of date. If I understand correctly, the mingw-w64 runtime > supports two different target triplets, the difference being based on > the vendor tag: with vendor=pc, it stays compatible with the mingw.org > runtime, while with vendor=w64, it enables some extensions.
The MinGW-w64 documentation does mention the MinGW-compatible runtime, but I'm not sure it's still supported - it's only referenced once as far as I can see, none of the actual build instructions take it into account, and I haven't found anything related to it in the configuration scripts. > NightStrike wrote[2]: > | On Wed, Dec 15, 2010 at 11:08 AM, Dmitrijs Ledkovs > | <dmitrij.led...@ubuntu.com> wrote: > > |> *nod* So is the best technical solution right now to create > |> <cpu>-<vendor>-windows GNU tripplet and slowly start patching > |> config.sub, config.guess and all of upstream projects? > | > | That's very debatable. I personally think it is, if you ignore 1) the > | politics of the matter, and 2) the ginormous amount of work required > | to update everything (though the transitional approach I mentioned > | eases that somewhat.) > [...] > | In fact, that's the very reason we started using the vendor > | tag for mingw-w64.sf.net-specific stuff. We got tired of debating > | with people as to what the $os part of the triplet should be. This is pretty much upstream's general opinion as far as changing the triplet is concerned... (Although I haven't asked recently.) > If mingw-w64 only adds extensions on top of the mingw.org runtime and > an app built against a mingw.org-built DLL will still run fine against > a mingw-w64-built DLL, then we could avoid all these questions and use > a single Debian arch for both. (That would be analagous to the case > of i386 and i686 being the same Debian arch.) If I have understood the > previous discussion correctly, that is not the case, and the mingw-w64 > and mingw.org ABIs are significantly different. > > Do we have an example? E.g., what happens if, targetting 32-bit > Windows: > > - I build my program against mingw-w64-built zlib, then try to > run it against mingw.org-built zlib That works fine. > - I build my program against a mingw-w64-built library that uses > more sophisticated features, like exceptions and threads, then > try to run it against the mingw.org-built version of the same > library I'm trying to find an example of this but so far haven't found anything that breaks, at least when using the compilers available in Debian (mingw32, which is the old gcc 4.2.1-based release of MinGW using SJLJ exception-handling; and gcc-mingw-w64, which uses gcc 4.6.3 again with SJLJ exception-handling). Thread-handling could cause problems, although both compilers use the basic Win32 thread-handling support; but I'm hoping to add pthreads support for Jessie - it's required for libgomp in particular. > If the ABIs really are significantly different, then it would > presumably be possible to move to a triplet like i686-pc-mingw32-w64 > or i686-w64-mingw32-w64 upstream. If the ABIs are compatible, then > dpkg can treat the existing tuples with -pc- and -w64- identically and > rely on package dependencies to pull in the appropriate packages at > build time or run time when it matters. > > And if we just don't know, we can leave it alone with an understanding > that we might need to rebuild everything to use a different multiarch > tuple later. > > Any of those three options seems fine to me. I prefer the latter option, even with the rebuild caveat. I don't see Debian's support for MinGW reviving any time soon, so compatibility with that is likely to remain a secondary concern - and if we can provide a good enough build environment within Debian using MinGW-w64, I don't see why that should be a problem. Regards, Stephen
signature.asc
Description: PGP signature
