Hi,
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.
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.
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
- 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
- etc
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.
Thanks,
Jonathan
[1] http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/1286
[2] http://bugs.debian.org/606825#100
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
