Greetings!
I recently became interested in cross-compiling software from Debian to
Windows. To my delight, I found the gcc-mingw-w64 & mingw-w64-tools
packages already in Debian (thanks Stephen!). However, I see that they
are using a workaround of a /usr/${triplet}/ path, rather than multi-arch.
Then found and read through this bug which hasn't seen an update in 5+
years :( Meanwhile, the Windows world has changed quite a bit in that
time, with Windows 10 being released in 2015, and Windows 7 due to go
EOL on 2020-01-14.
So, how can I best help the effort to get a proper multi-arch
infrastructure in Debian appropriate from cross-building using mingw-w64?
On 9/15/2014 11:46 AM, Guillem Jover wrote:
Hi!
On Tue, 2014-09-09 at 23:28:10 +0200, Stephen Kitt wrote:
On Sat, 30 Aug 2014 15:51:12 +0200, Guillem Jover <[email protected]> wrote:
But I just noticed that a proper triplet was accepted in the config.git
repo around 2012 (commit f16804b79ee5a23a9994a1cdc760cd9ba813148a), this
is what config.sub has to say:
$ /usr/share/misc/config.sub mingw64
x86_64-pc-mingw64
$ /usr/share/misc/config.sub x86_64-mingw64
x86_64-pc-mingw64
$ /usr/share/misc/config.sub i686-mingw64
i686-pc-mingw64
So, just one thought, if you are going to end up having to do the work
that would be required to add support for what amounts to the equivalent
of a new triplet, you could as well use a proper triplet, like the one
above?
That triplet was actually added by the MinGW project, not the MinGW-w64
project, and is intended for their putative 64-bit support, whenever that
appears;
Oh wow, even more confusion to the already confusing current situation.
I assume we cannot expect the mingw-w64 and the mingw64 ports to be ABI
compatible? :(
I'll take it up with MinGW-w64 upstream though and see what they make of it.
Thanks, that might help.
Did this conversation happen? Was there any result?
In the end it seems to me that as long as the triplet is officially
supported by config.sub/guess the rest of software should just follow
suit, which as mentioned before is what needs to be done for each and
every new architecture anyway. What might be more time consuming is
hunting down and updating the rest of the affected packages in Debian,
but given that this has been thought to be a partial architecture from
the beginning it should not amount to so many packages (in contrast to
a full fledged architecture, that is).
I think what will be time-consuming is getting the various required patches
into the various upstream projects; there are very few affected packages in
Debian. Unless you mean we should just go our own way, regardless of what
upstream thinks, and use the mingw64 which is already in config.sub and patch
whatever breaks?
Well, not really if that would mean making the situation even worse by
conflating what might end up being upstream projects tripping over
each other's triplets. (Sorry, this was not clear from the aforementioned
commit.)
I'd rather do the work required to get something supported properly in Debian
and by upstream...
Sure.
Thanks,
Guillem
Thanks,
--Joe
