Debian Bug report logs - #606825
dpkg: Please add mingw to ostable and triplettable.

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dpkg: Please add mingw to ostable and triplettable.

Date: Sun, 12 Dec 2010 00:36:36 +0000

[Message part 1 (text/plain, inline)]

Package: dpkg
Version: 1.15.8.6
Severity: wishlist
Tags: patch

config.guess has support for mingw32 since 2005. It accepts anything in the form
of *-*-mingw32. The "traditional", mingw.org based implementation, uses
<cpu>-pc-mingw32 triplet. Mingw-w64 based implementations, use
<cpu>-w64-mingw32. Gcc 4.5 and higher recognises -w64-mingw32 and enable
additional features for mingw-w64.

The attached patch produces desired values for Debian and GNU variables set by
dpkg-architecture.

[Message part 2 (application/pgp-signature, inline)]

[0001-Add-mingw32-w64-to-ostable-and-triplettable.patch (text/x-diff, inline)]

From 8315953b2bc7d400ed320b57e8eb5caed90e6da8 Mon Sep 17 00:00:00 2001
From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>
Date: Sun, 12 Dec 2010 00:15:22 +0000
Subject: [PATCH] Add mingw32-w64 to ostable and triplettable.

---
 ostable      |    1 +
 triplettable |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/ostable b/ostable
index 17b7581..1ee4277 100644
--- a/ostable
+++ b/ostable
@@ -31,3 +31,4 @@ bsd-openbsd		openbsd			openbsd[^-]*
 sysv-solaris		solaris			solaris[^-]*
 uclibceabi-uclinux	uclinux-uclibceabi	uclinux[^-]*-uclibceabi
 uclibc-uclinux		uclinux-uclibc		uclinux[^-]*(-uclibc.*)?
+w64-mingw32		w64-mingw32		mingw32[^-]*
diff --git a/triplettable b/triplettable
index 3e076e2..b374f2c 100644
--- a/triplettable
+++ b/triplettable
@@ -20,3 +20,4 @@ bsd-darwin-<cpu>	darwin-<cpu>
 sysv-solaris-<cpu>	solaris-<cpu>
 uclibceabi-uclinux-arm	uclinux-armel
 uclibc-uclinux-<cpu>	uclinux-<cpu>
+w64-mingw32-<cpu>	mingw-<cpu>
-- 
1.7.2.3

Message #10 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: 606825@bugs.debian.org

Subject: Re: dpkg: Please add mingw to ostable and triplettable.

Date: Sat, 11 Dec 2010 19:30:11 -0600

Hi,

Some uninformed reactions.

Dmitrijs Ledkovs wrote:

> --- a/ostable
> +++ b/ostable
> @@ -31,3 +31,4 @@ bsd-openbsd		openbsd			openbsd[^-]*
>  sysv-solaris		solaris			solaris[^-]*
>  uclibceabi-uclinux	uclinux-uclibceabi	uclinux[^-]*-uclibceabi
>  uclibc-uclinux		uclinux-uclibc		uclinux[^-]*(-uclibc.*)?
> +w64-mingw32		w64-mingw32		mingw32[^-]*

The ABI part (e.g., sysv-, gnu-, or bsd-) describes instruction set
variant and conventions for function calls, dynamic linking, and
program startup.  That last part often depends on libc.  In this case,
it is mingw-w64, abbreviated as w64, I suppose.  Why not plain
"mingw" --- are programs built with mingw32 unable to safely use DLLs
built with mingw64, for example?

The OS part (e.g., -linux) represents the kernel and maybe the
userland tools.  Should it be "winnt"?  What versions of Windows are
being targeted?

Functionally, the effect is to determine

	DEB_HOST_ARCH
	DEB_HOST_ARCH_OS
	DEB_HOST_GNU_TYPE

for use by debian/rules when building packages targeted at that
system.  (I know you realize this, just reminding myself!)

> Gcc 4.5 and higher recognises -w64-mingw32

So the value in the "GNU name" column is correct.

Message #15 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: dpkg: Please add mingw to ostable and triplettable.

Date: Sun, 12 Dec 2010 09:56:28 +0000

CC: mingw-w64 mailing list

I'm asking to add mingw32-w64 tripplet and os to dpkg. Please suggest
/ improve how you would like to have debian or tripplet be called. We
are settled that GNU tripplet will be <cpu>-w64-mingw32 =)

On 12 December 2010 01:30, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> Some uninformed reactions.
>

Thank you for shedding some more lights of what ABI/OS parts should mean!

> Dmitrijs Ledkovs wrote:
>
>> --- a/ostable
>> +++ b/ostable
>> @@ -31,3 +31,4 @@ bsd-openbsd         openbsd                 openbsd[^-]*
>>  sysv-solaris         solaris                 solaris[^-]*
>>  uclibceabi-uclinux   uclinux-uclibceabi      uclinux[^-]*-uclibceabi
>>  uclibc-uclinux               uclinux-uclibc          uclinux[^-]*(-uclibc.*)?
>> +w64-mingw32          w64-mingw32             mingw32[^-]*
>
> The ABI part (e.g., sysv-, gnu-, or bsd-) describes instruction set
> variant and conventions for function calls, dynamic linking, and
> program startup.  That last part often depends on libc.  In this case,
> it is mingw-w64, abbreviated as w64, I suppose.  Why not plain
> "mingw" --- are programs built with mingw32 unable to safely use DLLs
> built with mingw64, for example?
>

"The ABI part describes instruction set variant etc"
"That last part often depends on libc"

----8<----
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360587#35
On Thu, Sep 06, 2007 at 12:08:10PM -0500, Tony J. White wrote:
>
> Why was the name 'i586-mingw32msvc' choosen?

To indicate the target binaries for this build use the msvcrt runtime.
----8<----

There are currently two free implementations of msvcrt: mingw.org and mingw-w64.
Programs built with mingw32 *unable* to safely use DLLs built with
mingw64 there are subtle differences in implementations. The biggest
one is that mingw-w64 is 32/64 bit aware.

> The OS part (e.g., -linux) represents the kernel and maybe the
> userland tools.  Should it be "winnt"?  What versions of Windows are
> being targeted?
>
winnt is okish, but see further. mingw-w64 compiles for Windows XP and
it has additional headers for compatability and features of Vista and
7.

We have one ABI (windows-like) and then for OS parts it could be
"native" - msvcrt or "unix-like" - cygwin. For free kernel options we
have ReactOS and linux+wine. For msvcrt we have options of using mingw
and w64. So maybe something like this:

Debian name:
ms-msvcrt
ms-cygwin

And then it's up to Debian maintainers which msvcrt implementation
(analogy with libc) to use - mingw.org or w64 (this one). We can
package both to test and compare and find bugs, etc.

The "original" now zomby debian-win32@l.d.o was aiming to create
ms-cygwin port.

> Functionally, the effect is to determine
>
>        DEB_HOST_ARCH
>        DEB_HOST_ARCH_OS
>        DEB_HOST_GNU_TYPE
>
> for use by debian/rules when building packages targeted at that
> system.  (I know you realize this, just reminding myself!)
>
>> Gcc 4.5 and higher recognises -w64-mingw32
>
> So the value in the "GNU name" column is correct.
>

Message #20 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: dpkg: Please add mingw to ostable and triplettable.

Date: Mon, 13 Dec 2010 17:21:59 -0600

Dmitrijs Ledkovs wrote:

> There are currently two free implementations of msvcrt: mingw.org and mingw-w64.
> Programs built with mingw32 *unable* to safely use DLLs built with
> mingw64 there are subtle differences in implementations.

That answers my main question.  Then I suppose:

> We have one ABI (windows-like) and then for OS parts it could be
> "native" - msvcrt or "unix-like" - cygwin. For free kernel options we
> have ReactOS and linux+wine. For msvcrt we have options of using mingw
> and w64. So maybe something like this:
>
> Debian name:
> ms-msvcrt
> ms-cygwin

mingw32-winnt
mingw64-winnt
mingw32-msys
mingw64-msys
mingw32-cygwin
mingw64-cygwin

(Obviously I am not attached to the names, just trying to figure
out which targets need distinct Debian names for compatibility.)

Presumably at the moment you're be working on mingw64-winnt?

> And then it's up to Debian maintainers which msvcrt implementation
> (analogy with libc) to use - mingw.org or w64 (this one). We can
> package both to test and compare and find bugs, etc.

Ah, interesting.

Thanks again.  Others wiser than I am can presumably take it from
here.

Message #25 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: dpkg: Please add mingw to ostable and triplettable.

Date: Tue, 14 Dec 2010 00:26:50 +0000

On 13 December 2010 23:21, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Dmitrijs Ledkovs wrote:
>
>> There are currently two free implementations of msvcrt: mingw.org and mingw-w64.
>> Programs built with mingw32 *unable* to safely use DLLs built with
>> mingw64 there are subtle differences in implementations.
>
> That answers my main question.  Then I suppose:
>
>> We have one ABI (windows-like) and then for OS parts it could be
>> "native" - msvcrt or "unix-like" - cygwin. For free kernel options we
>> have ReactOS and linux+wine. For msvcrt we have options of using mingw
>> and w64. So maybe something like this:
>>
>> Debian name:
>> ms-msvcrt
>> ms-cygwin
>
> mingw32-winnt
> mingw64-winnt
> mingw32-msys
> mingw64-msys
> mingw32-cygwin
> mingw64-cygwin
>

----8<----
MSYS is a collection of GNU utilities such as bash, make, gawk and
grep to allow building of applications and programs which depend on
traditionally UNIX tools to be present. It is intended to supplement
MinGW and the deficiencies of the cmd shell.
----8<----

So msys is just a meta-package which runs on mingwXX-winnt.

I like:

mingw32-winnt - mingw.org based, Windows native port
mingw64-winnt - mingw-w64 based, Windows native port
mingw32-cygwin - mingw.org based toolchain for/with cygwin port
mingw64-cygwin - mingw-w64 based toolchain for/with cygwin port

All four of the both multipled by available cpu's resulting in these
GNU triplets

mingw32-winnt - <cpu>-pc-mingw32
mingw64-winnt - <cpu>-w64-mingw32
mingw32-cygwin - <cpu>-pc-cygwin
mingw64-cygwin - <cpu>-w64-cygwin

> (Obviously I am not attached to the names, just trying to figure
> out which targets need distinct Debian names for compatibility.)
>

All four of the above triplets make sense and are "in the wild out
there not packaged in Debian"

> Presumably at the moment you're be working on mingw64-winnt?
>

Yes. For i386 and amd64 Debian cpu's.

>> And then it's up to Debian maintainers which msvcrt implementation
>> (analogy with libc) to use - mingw.org or w64 (this one). We can
>> package both to test and compare and find bugs, etc.
>
> Ah, interesting.
>
> Thanks again.  Others wiser than I am can presumably take it from
> here.
>

Shall I provide an updated patch against dpkg?

With regards,

Dmitrijs.

Message #30 received at 606825@bugs.debian.org (full text, mbox, reply):

From: NightStrike <nightstrike@gmail.com>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Tue, 14 Dec 2010 07:52:43 -0500

On Sun, Dec 12, 2010 at 4:56 AM, Dmitrijs Ledkovs
<dmitrij.ledkov@ubuntu.com> wrote:
> CC: mingw-w64 mailing list
>
> I'm asking to add mingw32-w64 tripplet and os to dpkg. Please suggest
> / improve how you would like to have debian or tripplet be called. We
> are settled that GNU tripplet will be <cpu>-w64-mingw32 =)

What is the debian triplet as compared to the GNU triplet?

As for the GNU triplet, the important part is the vendor tag, the
-w64- in the middle.  The rest is flexible.  You could, for instance,
drop the 32 on mingw32, as most config.guess scripts have been updated
for the past couple years now to use mingw* to wildcard out the 32, as
it no longer has any meaning.

That part should eventually just be called "windows", for instance in
x86_64-w64-windows.

Message #35 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Andy Koppe <andy.koppe@gmail.com>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Tue, 14 Dec 2010 13:20:49 +0000

On 14 December 2010 00:26, Dmitrijs Ledkovs wrote:
>> mingw32-winnt
>> mingw64-winnt
>> mingw32-msys
>> mingw64-msys
>> mingw32-cygwin
>> mingw64-cygwin
>>
>
> ----8<----
> MSYS is a collection of GNU utilities such as bash, make, gawk and
> grep to allow building of applications and programs which depend on
> traditionally UNIX tools to be present. It is intended to supplement
> MinGW and the deficiencies of the cmd shell.
> ----8<----
>
> So msys is just a meta-package which runs on mingwXX-winnt.

It's not. It's a fork of an old Cygwin version (1.3), with increased
emphasis on Windows integration. It has its own toolchain, and it
makes a big difference whether you build a program for MinGW or MSYS.
In particular, the MSYS DLL (née Cygwin DLL) does provide a fair chunk
of POSIX, whereas MinGW basically sticks with what Windows itself
provides.

Andy

Message #40 received at 606825@bugs.debian.org (full text, mbox, reply):

From: JonY <jon_y@users.sourceforge.net>

To: Andy Koppe <andy.koppe@gmail.com>

Cc: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>, Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Tue, 14 Dec 2010 22:37:40 +0800

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/14/2010 21:20, Andy Koppe wrote:
> On 14 December 2010 00:26, Dmitrijs Ledkovs wrote:
>>> mingw32-winnt
>>> mingw64-winnt
>>> mingw32-msys
>>> mingw64-msys
>>> mingw32-cygwin
>>> mingw64-cygwin
>>>
>>
>> ----8<----
>> MSYS is a collection of GNU utilities such as bash, make, gawk and
>> grep to allow building of applications and programs which depend on
>> traditionally UNIX tools to be present. It is intended to supplement
>> MinGW and the deficiencies of the cmd shell.
>> ----8<----
>>
>> So msys is just a meta-package which runs on mingwXX-winnt.
> 
> It's not. It's a fork of an old Cygwin version (1.3), with increased
> emphasis on Windows integration. It has its own toolchain, and it
> makes a big difference whether you build a program for MinGW or MSYS.
> In particular, the MSYS DLL (née Cygwin DLL) does provide a fair chunk
> of POSIX, whereas MinGW basically sticks with what Windows itself
> provides.
> 
> Andy
> 

Anybody needing POSIXness and developing on MSYS should really try
Cygwin instead. MSYS is more of a mingw support platform (to run
configure shell scripts etc) than a an actual platform on its own.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)

iEYEARECAAYFAk0HgTMACgkQp56AKe10wHdg7gCgg0OaWzj+xmoAgp0FtQv+U89u
vBMAn1pvQ8QhbE1Y2goFoTf2dmggX/jb
=+N6l
-----END PGP SIGNATURE-----

[0xED74C077.asc (application/pgp-keys, attachment)]

Message #45 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: NightStrike <nightstrike@gmail.com>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Tue, 14 Dec 2010 16:38:34 +0000

On 14 December 2010 12:52, NightStrike <nightstrike@gmail.com> wrote:
> On Sun, Dec 12, 2010 at 4:56 AM, Dmitrijs Ledkovs
> <dmitrij.ledkov@ubuntu.com> wrote:
>> CC: mingw-w64 mailing list
>>
>> I'm asking to add mingw32-w64 tripplet and os to dpkg. Please suggest
>> / improve how you would like to have debian or tripplet be called. We
>> are settled that GNU tripplet will be <cpu>-w64-mingw32 =)
>
> What is the debian triplet as compared to the GNU triplet?
>

$ cat dpkg/ostable
# This file contains the table of known operating system names.
#
# Architecture names are formed as a combination of the system name
# (from this table) and CPU name (from cputable) after mapping from
# the Debian triplet (from triplettable). A list of architecture
# names in the Debian ‘sid’ distribution can be found in the archtable
# file.
#
# Column 1 is the Debian name for the system, used to form the system part
# in the Debian triplet.
# Column 2 is the GNU name for the system, used to output build and host
# targets in ‘dpkg-architecture’.
# Column 3 is an extended regular expression used to match against the
# system part of the output of the GNU config.guess script.
#
# <Debian name>		<GNU name>		<config.guess regex>
uclibceabi-linux	linux-uclibceabi	linux[^-]*-uclibceabi
uclibc-linux		linux-uclibc		linux[^-]*-uclibc
gnueabi-linux		linux-gnueabi		linux[^-]*-gnueabi
gnuspe-linux		linux-gnuspe		linux[^-]*-gnuspe
gnulp-linux		linux-gnulp		linux[^-]*-gnulp
gnu-linux		linux-gnu		linux[^-]*(-gnu.*)?
gnu-kfreebsd		kfreebsd-gnu		kfreebsd[^-]*(-gnu.*)?
gnu-knetbsd		knetbsd-gnu		knetbsd[^-]*(-gnu.*)?
gnu-kopensolaris	kopensolaris-gnu	kopensolaris[^-]*(-gnu.*)?
gnu-hurd		gnu			gnu[^-]*
bsd-darwin		darwin			darwin[^-]*
bsd-freebsd		freebsd			freebsd[^-]*
bsd-netbsd		netbsd			netbsd[^-]*
bsd-openbsd		openbsd			openbsd[^-]*
sysv-solaris		solaris			solaris[^-]*
uclibceabi-uclinux	uclinux-uclibceabi	uclinux[^-]*-uclibceabi
uclibc-uclinux		uclinux-uclibc		uclinux[^-]*(-uclibc.*)?

$ cat triplettable
# Bidirectional mapping between a Debian triplet and a Debian arch.
#
# Supported variables: <cpu>
#
# <Debian triplet>	<Debian arch>
uclibceabi-linux-arm	uclibc-linux-armel
uclibc-linux-<cpu>	uclibc-linux-<cpu>
gnueabi-linux-arm	armel
gnuspe-linux-powerpc	powerpcspe
gnulp-linux-i386	lpia
gnu-linux-<cpu>		<cpu>
gnu-kfreebsd-<cpu>	kfreebsd-<cpu>
gnu-knetbsd-<cpu>	knetbsd-<cpu>
gnu-kopensolaris-<cpu>	kopensolaris-<cpu>
gnu-hurd-<cpu>		hurd-<cpu>
bsd-freebsd-<cpu>	freebsd-<cpu>
bsd-openbsd-<cpu>	openbsd-<cpu>
bsd-netbsd-<cpu>	netbsd-<cpu>
bsd-darwin-<cpu>	darwin-<cpu>
sysv-solaris-<cpu>	solaris-<cpu>
uclibceabi-uclinux-arm	uclinux-armel
uclibc-uclinux-<cpu>	uclinux-<cpu>


From above two tables:

solaris-amd64 (this is used in debian/control and in the last part of
the deb binary package name) is sysv-solaris-amd64 Debian port which
corresponds to x86_64-*-solaris GNU triplet.

> As for the GNU triplet, the important part is the vendor tag, the
> -w64- in the middle. &nbsp;The rest is flexible. &nbsp;You could, for instance,
> drop the 32 on mingw32, as most config.guess scripts have been updated
> for the past couple years now to use mingw* to wildcard out the 32, as
> it no longer has any meaning.
>

For computability we have already agreed to have GNU tripplet
i686/x86_64-w64-mingw32 for the mingw-w64 debian port. We are now
trying to figure out how to correctly call Debian OS which is
"mingw-w64 based".

And to correctly create a consistent name for Debian "mingw-w64 based"
OS we are also trying to define other ports which are different from
"mingw-w64" ABI-wise.

> That part should eventually just be called "windows", for instance in
> x86_64-w64-windows.
>

So in the hypothetical future on my i686 machine I could be able to install:

windows-mingw - operating system which links against mingw.org runtime
(GNU triplet <cpu>-pc-mingw32)
windows-w64 - operating system which links against mingw-w64 runtime
and uses e.g. w64-projects threads implementation (GNU triplet
<cpu>-w64-mingw32)
windows-cygwin - operating system which links against cygwin.dll (GNU
triplet <cpu>-pc-cygwin)
windows-msys - operating system which runs inside msys environment
(GNU triplet ???)

Are above OS all different enough to require separate toolchains and
require recompiling all packages in Debian archive?

What OS do we get when we use w64 on cygwin? Is that a cross compiler?

With regards,

Dmitrijs.

Message #50 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: Andy Koppe <andy.koppe@gmail.com>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Tue, 14 Dec 2010 16:41:19 +0000

On 14 December 2010 13:20, Andy Koppe <andy.koppe@gmail.com> wrote:
> On 14 December 2010 00:26, Dmitrijs Ledkovs wrote:
>>> mingw32-winnt
>>> mingw64-winnt
>>> mingw32-msys
>>> mingw64-msys
>>> mingw32-cygwin
>>> mingw64-cygwin
>>>
>>
>> ----8<----
>> MSYS is a collection of GNU utilities such as bash, make, gawk and
>> grep to allow building of applications and programs which depend on
>> traditionally UNIX tools to be present. It is intended to supplement
>> MinGW and the deficiencies of the cmd shell.
>> ----8<----
>>
>> So msys is just a meta-package which runs on mingwXX-winnt.
>
> It's not. It's a fork of an old Cygwin version (1.3), with increased
> emphasis on Windows integration. It has its own toolchain, and it
> makes a big difference whether you build a program for MinGW or MSYS.
> In particular, the MSYS DLL (née Cygwin DLL) does provide a fair chunk
> of POSIX, whereas MinGW basically sticks with what Windows itself
> provides.
>
> Andy
>

What is GNU triplet for MSYS then? How different it is from the MinGW
tripplet? Is it just a different ABI then?

mingw-winnt - MinGW
mingw-msys - MSYS
w64-winnt - Mingw-w64 project
cygwin-winnt - Cygwin

???

Message #55 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Ruben Van Boxem <vanboxem.ruben@gmail.com>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: Andy Koppe <andy.koppe@gmail.com>, Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Tue, 14 Dec 2010 17:49:53 +0100

2010/12/14 Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>
>
> On 14 December 2010 13:20, Andy Koppe <andy.koppe@gmail.com> wrote:
> > On 14 December 2010 00:26, Dmitrijs Ledkovs wrote:
> >>> mingw32-winnt
> >>> mingw64-winnt
> >>> mingw32-msys
> >>> mingw64-msys
> >>> mingw32-cygwin
> >>> mingw64-cygwin
> >>>
> >>
> >> ----8<----
> >> MSYS is a collection of GNU utilities such as bash, make, gawk and
> >> grep to allow building of applications and programs which depend on
> >> traditionally UNIX tools to be present. It is intended to supplement
> >> MinGW and the deficiencies of the cmd shell.
> >> ----8<----
> >>
> >> So msys is just a meta-package which runs on mingwXX-winnt.
> >
> > It's not. It's a fork of an old Cygwin version (1.3), with increased
> > emphasis on Windows integration. It has its own toolchain, and it
> > makes a big difference whether you build a program for MinGW or MSYS.
> > In particular, the MSYS DLL (née Cygwin DLL) does provide a fair chunk
> > of POSIX, whereas MinGW basically sticks with what Windows itself
> > provides.
> >
> > Andy
> >
>
> What is GNU triplet for MSYS then? How different it is from the MinGW
> tripplet? Is it just a different ABI then?

The GNU triplet for MSYS is "i686-pc-msys". It compiles to a binary
linked to msys-*.dll comparable to how cygwin works (it emulates POSIX
as much as implemented). It is a form of virtualization on Windows to
provide a minimalist POSIX environment. MinGW(-w64) is basically GCC
for the Microsoft CRT with some very limited extensions for some basic
POSIX functionality (rather unusable, but still present). It compiles
native Win32 applications, just like MSVC does.
Msys is a different ABI from mingw(-w64) tries to stick as close to
MSVC's as possible.
>
> mingw-winnt - MinGW
> mingw-msys - MSYS


>
> w64-winnt - Mingw-w64 project

This would not show the connection between mingw.org and mingw-w64,
which are two "parallel" projects, one which adds more functionality
(like a x64 compile path and associated functionality, an experimental
threading API for std::thread/libgomp type stuff).

>
> cygwin-winnt - Cygwin
>
> ???
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Message #60 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Andy Koppe <andy.koppe@gmail.com>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Tue, 14 Dec 2010 16:55:54 +0000

On 14 December 2010 16:41, Dmitrijs Ledkovs wrote:
> On 14 December 2010 13:20, Andy Koppe wrote:
> What is GNU triplet for MSYS then? How different it is from the MinGW
> tripplet? Is it just a different ABI then?
>
> mingw-winnt - MinGW
> mingw-msys - MSYS
> w64-winnt - Mingw-w64 project
> cygwin-winnt - Cygwin

MinGW: i686-pc-mingw32
MSYS: i686-pc-msys
Cygwin: i686-pc-cygwin

(Those are all 32-bit platforms.)

Not quite sure about MinGW-w64, but JonY's Cygwin-hosted tools use:

MinGW-w64 32-bit: i686-w64-mingw32
MinGW-w64 64-bit: x86_64-w64-mingw32

Message #65 received at 606825@bugs.debian.org (full text, mbox, reply):

From: JonY <jon_y@users.sourceforge.net>

To: Andy Koppe <andy.koppe@gmail.com>

Cc: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>, Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Wed, 15 Dec 2010 07:45:06 +0800

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/15/2010 00:55, Andy Koppe wrote:
> On 14 December 2010 16:41, Dmitrijs Ledkovs wrote:
>> On 14 December 2010 13:20, Andy Koppe wrote:
>> What is GNU triplet for MSYS then? How different it is from the MinGW
>> tripplet? Is it just a different ABI then?
>>
>> mingw-winnt - MinGW
>> mingw-msys - MSYS
>> w64-winnt - Mingw-w64 project
>> cygwin-winnt - Cygwin
> 
> MinGW: i686-pc-mingw32
> MSYS: i686-pc-msys
> Cygwin: i686-pc-cygwin
> 
> (Those are all 32-bit platforms.)
> 
> Not quite sure about MinGW-w64, but JonY's Cygwin-hosted tools use:
> 
> MinGW-w64 32-bit: i686-w64-mingw32
> MinGW-w64 64-bit: x86_64-w64-mingw32
> 

Yes, this is correct. The "w64" vendor key is a keyword to gcc to
activate additional features like unicode startups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)

iEYEARECAAYFAk0IAYEACgkQp56AKe10wHciawCfUZlvYKEKuxfjfpb7X85+UKIG
sOEAn0pr+kgPHRe3DtITz745wnTrmY5Q
=qpgt
-----END PGP SIGNATURE-----

[0xED74C077.asc (application/pgp-keys, attachment)]

Message #70 received at 606825@bugs.debian.org (full text, mbox, reply):

From: NightStrike <nightstrike@gmail.com>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Wed, 15 Dec 2010 08:36:09 -0500

On 12/14/10, Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com> wrote:
> $ cat dpkg/ostable
> # This file contains the table of known operating system names.
> #
> # Architecture names are formed as a combination of the system name
> # (from this table) and CPU name (from cputable) after mapping from
> # the Debian triplet (from triplettable). A list of architecture
> # names in the Debian ‘sid’ distribution can be found in the archtable
> # file.
> #
> # Column 1 is the Debian name for the system, used to form the system part
> # in the Debian triplet.
> # Column 2 is the GNU name for the system, used to output build and host
> # targets in ‘dpkg-architecture’.
> # Column 3 is an extended regular expression used to match against the
> # system part of the output of the GNU config.guess script.


So.... debian renames all of the existing GNU triplets that are
standardized?  Why is that at all necessary?


>> As for the GNU triplet, the important part is the vendor tag, the
>> -w64- in the middle. &nbsp;The rest is flexible. &nbsp;You could, for
>> instance,
>> drop the 32 on mingw32, as most config.guess scripts have been updated
>> for the past couple years now to use mingw* to wildcard out the 32, as
>> it no longer has any meaning.
>>
>
> For computability we have already agreed to have GNU tripplet
> i686/x86_64-w64-mingw32 for the mingw-w64 debian port. We are now
> trying to figure out how to correctly call Debian OS which is
> "mingw-w64 based".
>
> And to correctly create a consistent name for Debian "mingw-w64 based"
> OS we are also trying to define other ports which are different from
> "mingw-w64" ABI-wise.

What's wrong with using the existing GNU triplet?


>> That part should eventually just be called "windows", for instance in
>> x86_64-w64-windows.
>>
>
> So in the hypothetical future on my i686 machine I could be able to install:
>
> windows-mingw - operating system which links against mingw.org runtime
> (GNU triplet <cpu>-pc-mingw32)
> windows-w64 - operating system which links against mingw-w64 runtime
> and uses e.g. w64-projects threads implementation (GNU triplet
> <cpu>-w64-mingw32)
> windows-cygwin - operating system which links against cygwin.dll (GNU
> triplet <cpu>-pc-cygwin)
> windows-msys - operating system which runs inside msys environment
> (GNU triplet ???)

No, I was referring to the GNU triplet.  We've talked extensively
about the logical collapse into <cpu>-<vendor>-windows, where the
vendor key determines if it's from mingw.org, mingw-w64.sf.net, or any
other place.

I don't undrestand the naming structure or purpose of these
debianisms, but if you start out fresh using "windows" to signify
windows platforms, that seems logically sound.

> Are above OS all different enough to require separate toolchains and
> require recompiling all packages in Debian archive?

Yes.  Binaries compiled with mingw-w64 toolchains, even those that
target 32-bit, are not guaranteed to be compatible with those of
mingw.org.

> What OS do we get when we use w64 on cygwin? Is that a cross compiler?

If you install JonY's packages, they are all cross compilers to
generate either 32- or 64-bit native windows binaries from a cygwin
host.

Message #75 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: NightStrike <nightstrike@gmail.com>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Wed, 15 Dec 2010 16:08:36 +0000

On 15 December 2010 13:36, NightStrike <nightstrike@gmail.com> wrote:
> On 12/14/10, Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com> wrote:
>> $ cat dpkg/ostable
>> # This file contains the table of known operating system names.
>> #
>> # Architecture names are formed as a combination of the system name
>> # (from this table) and CPU name (from cputable) after mapping from
>> # the Debian triplet (from triplettable). A list of architecture
>> # names in the Debian ‘sid’ distribution can be found in the archtable
>> # file.
>> #
>> # Column 1 is the Debian name for the system, used to form the system part
>> # in the Debian triplet.
>> # Column 2 is the GNU name for the system, used to output build and host
>> # targets in ‘dpkg-architecture’.
>> # Column 3 is an extended regular expression used to match against the
>> # system part of the output of the GNU config.guess script.
>
>
> So.... debian renames all of the existing GNU triplets that are
> standardized?  Why is that at all necessary?
>

To define a new dpkg architecture.
To define a new name.
Often it is necessary when GNU triplets is doesn't exist, not
standardized or multiple triplets are used.

E.g. Gnu/kfreebsd port and msys (no triplet in upstream git checkout
of config.guess and config.sub)

>
>>> As for the GNU triplet, the important part is the vendor tag, the
>>> -w64- in the middle. &nbsp;The rest is flexible. &nbsp;You could, for
>>> instance,
>>> drop the 32 on mingw32, as most config.guess scripts have been updated
>>> for the past couple years now to use mingw* to wildcard out the 32, as
>>> it no longer has any meaning.
>>>
>>
>> For computability we have already agreed to have GNU tripplet
>> i686/x86_64-w64-mingw32 for the mingw-w64 debian port. We are now
>> trying to figure out how to correctly call Debian OS which is
>> "mingw-w64 based".
>>
>> And to correctly create a consistent name for Debian "mingw-w64 based"
>> OS we are also trying to define other ports which are different from
>> "mingw-w64" ABI-wise.
>
> What's wrong with using the existing GNU triplet?
>

Nothing is wrong. We can use <cpu>-w64-mingw32 for GNU triplet and
make up any debian name for it. It is best if debian name has meaning
is consistent with other similar arches.

>
>>> That part should eventually just be called "windows", for instance in
>>> x86_64-w64-windows.
>>>
>>
>> So in the hypothetical future on my i686 machine I could be able to install:
>>
>> windows-mingw - operating system which links against mingw.org runtime
>> (GNU triplet <cpu>-pc-mingw32)
>> windows-w64 - operating system which links against mingw-w64 runtime
>> and uses e.g. w64-projects threads implementation (GNU triplet
>> <cpu>-w64-mingw32)
>> windows-cygwin - operating system which links against cygwin.dll (GNU
>> triplet <cpu>-pc-cygwin)
>> windows-msys - operating system which runs inside msys environment
>> (GNU triplet ???)
>
> No, I was referring to the GNU triplet.  We've talked extensively
> about the logical collapse into <cpu>-<vendor>-windows, where the
> vendor key determines if it's from mingw.org, mingw-w64.sf.net, or any
> other place.
>

Currently config.sub prefers winnt

        -windowsnt*)
                os=`echo $os | sed -e 's/windowsnt/winnt/'`
                ;;

And I don't see config.sub and config.guess recognising <vendor>-windows.

Creating a patch which will make config.sub and config.guess recognise
<cpu>-w64-windows, <cpu>-mingw-windows, <cpu>-msys-windows and
<cpu>-cygwin-windows is IMHO a radical change. Loads of software will
needs to be patched to recognise vendor tag and not depend on *mingw32
in their configure scripts.

Would you be willing to provide a patch against config.sub and
config.guess? Such patch could be integrated into autotools-dev in
Debian and the rest of software can be patched as described above. It
will be a painful transition requiring loads of work. I cannot commit
to doing it.

I'd rather use windows-<vendor> as Debian OS Name and continue using
existing Gnu tripplets (-w64-mingw32, -pc-mingw32, *-cygwin, *-msys)

> I don't undrestand the naming structure or purpose of these
> debianisms, but if you start out fresh using "windows" to signify
> windows platforms, that seems logically sound.
>

*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? Are
cygwin/msys/mingw people willing to support new triplet naming scheme?

I personally would rather work now using existing GNU tripplets (e.g.
<cpu>-w64-mingw32), call debian arch as win[dows|nt]-<vendor> and
continue like that. At a later date we can switch the gnu ports to the
fresh GNU tripplets <cpu>-<vendor>-windows onces cygwin, mingw and
msys upstream agree to support that. The first transition can happen
within Debian archive, I just don't want Debian to be the only one to
have "a different GNU triplet not used by anyone else".

>> Are above OS all different enough to require separate toolchains and
>> require recompiling all packages in Debian archive?
>
> Yes.  Binaries compiled with mingw-w64 toolchains, even those that
> target 32-bit, are not guaranteed to be compatible with those of
> mingw.org.
>

Ok.

>> What OS do we get when we use w64 on cygwin? Is that a cross compiler?
>
> If you install JonY's packages, they are all cross compilers to
> generate either 32- or 64-bit native windows binaries from a cygwin
> host.
>

Ok.

Message #80 received at 606825@bugs.debian.org (full text, mbox, reply):

From: JonY <jon_y@users.sourceforge.net>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: NightStrike <nightstrike@gmail.com>, Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Thu, 16 Dec 2010 07:34:59 +0800

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/16/2010 00:08, Dmitrijs Ledkovs wrote:
> On 15 December 2010 13:36, NightStrike <nightstrike@gmail.com> wrote:
>> On 12/14/10, Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com> wrote:
>>> $ cat dpkg/ostable
>>> # This file contains the table of known operating system names.
>>> #
>>> # Architecture names are formed as a combination of the system name
>>> # (from this table) and CPU name (from cputable) after mapping from
>>> # the Debian triplet (from triplettable). A list of architecture
>>> # names in the Debian ‘sid’ distribution can be found in the archtable
>>> # file.
>>> #
>>> # Column 1 is the Debian name for the system, used to form the system part
>>> # in the Debian triplet.
>>> # Column 2 is the GNU name for the system, used to output build and host
>>> # targets in ‘dpkg-architecture’.
>>> # Column 3 is an extended regular expression used to match against the
>>> # system part of the output of the GNU config.guess script.
>>
>>
>> So.... debian renames all of the existing GNU triplets that are
>> standardized?  Why is that at all necessary?
>>
> 
> To define a new dpkg architecture.
> To define a new name.
> Often it is necessary when GNU triplets is doesn't exist, not
> standardized or multiple triplets are used.
> 
> E.g. Gnu/kfreebsd port and msys (no triplet in upstream git checkout
> of config.guess and config.sub)
> 

MSYS isn't there for a reason, its not meant to be used as a platform on
its own. Its there to support mingw on Windows. Windows doesn't come
with a shell interpreter.

It really shouldn't be in config.guess. You should use Cygwin if you
want use unix-ish conventions on Windows.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)

iEYEARECAAYFAk0JUKMACgkQp56AKe10wHcCfQCcCvH+gL6GPyrdFJRpT1ZERw0O
ALgAnjjv/Go9ZJALiPsThdpNhXXKvkCq
=MNjy
-----END PGP SIGNATURE-----

[0xED74C077.asc (application/pgp-keys, attachment)]

Message #85 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Earnie <earnie@users.sourceforge.net>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: Andy Koppe <andy.koppe@gmail.com>, Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Thu, 16 Dec 2010 09:12:44 -0500

Dmitrijs Ledkovs wrote:
>
> What is GNU triplet for MSYS then? How different it is from the
> MinGW tripplet? Is it just a different ABI then?
>

There should never be a publicly declared triplet for MSYS.  We have
stated that it is a private matter since only the developers of MSYS
would use it.

<quote site="http://www.mingw.org/wiki/MSYS">
A common misunderstanding is MSYS is "UNIX on Windows", MSYS by itself
does not contain a compiler or a C library, therefore does not give the
ability to magically port UNIX programs over to Windows nor does it
provide any UNIX specific functionality like case-sensitive filenames.
Users looking for such functionality should look to Cygwin
<http://www.mingw.org/wiki/Cygwin> or Microsoft's Interix
<http://www.mingw.org/wiki/Interix> instead.
</quote>

Earnie

Message #90 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: mingw64 <mingw-w64-public@lists.sourceforge.net>

Cc: Andy Koppe <andy.koppe@gmail.com>, Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Thu, 16 Dec 2010 16:56:38 +0000

On 16 December 2010 14:12, Earnie <earnie@users.sourceforge.net> wrote:
> Dmitrijs Ledkovs wrote:
>>
>> What is GNU triplet for MSYS then? How different it is from the
>> MinGW tripplet? Is it just a different ABI then?
>>
>
> There should never be a publicly declared triplet for MSYS. &nbsp;We have
> stated that it is a private matter since only the developers of MSYS
> would use it.
>

Fair enough.
How is it compiled from source (bootstrap steps if such are required)?
What compiler do you use to compile MSYS from source?
Does it make sense to have msys-compatible precompiled Gtk, Qt etc
available from Debian-Msys port?
Can I use compiled for mingw.org libraries in MSYS environment?
Can I use compiled for mingw-w64 libraries in MSYS environment?
Can I use Visual Studio compiled libraries in MSYS environment?

The answers to above questions will tell us whether dpkg should have
msys defined as debian-arch/os.

> <quote site="http://www.mingw.org/wiki/MSYS">
> A common misunderstanding is MSYS is "UNIX on Windows", MSYS by itself
> does not contain a compiler or a C library, therefore does not give the
> ability to magically port UNIX programs over to Windows nor does it
> provide any UNIX specific functionality like case-sensitive filenames.
> Users looking for such functionality should look to Cygwin
> <http://www.mingw.org/wiki/Cygwin> or Microsoft's Interix
> <http://www.mingw.org/wiki/Interix> instead.
> </quote>
>

I have read the website. My first understanding that it is user-space
around Mingw.org runtime which runs on Windows platforms to provide
user tools to e.g. have a shell capable of running autoconf and etc.
Thus I thought that we can provide msys as a suite of packages
compiled as part of Debian-Mingw port. That way you could install
Debian-Mingw port in a chroot and instead of using cross-compiler use
e.g. linux + wine + msys = to get msys shell which is equivalent to
msys shell on Windows.

Hope this makes sense. As you can see I'm not entirely sure what MSYS
is and what MSYS isn't and where that border lies on the
mingw-cygwin-w64 spectrum.

> Earnie
>

With regards,

Dmitrijs.

Message #95 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: mingw64 <mingw-w64-public@lists.sourceforge.net>

Cc: 606825@bugs.debian.org, NightStrike <nightstrike@gmail.com>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Thu, 16 Dec 2010 16:57:41 +0000

What is GNU triplet for ReactOS?

Should we define a separate Debian-arch/os for ReactOS?

Regards,
Dmitrijs.

Message #100 received at 606825@bugs.debian.org (full text, mbox, reply):

From: NightStrike <nightstrike@gmail.com>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Thu, 16 Dec 2010 14:18:26 -0500

On Wed, Dec 15, 2010 at 11:08 AM, Dmitrijs Ledkovs
<dmitrij.ledkov@ubuntu.com> wrote:
> To define a new dpkg architecture.
> To define a new name.
> Often it is necessary when GNU triplets is doesn't exist, not
> standardized or multiple triplets are used.
>
> E.g. Gnu/kfreebsd port and msys (no triplet in upstream git checkout
> of config.guess and config.sub)
>
>> What's wrong with using the existing GNU triplet?
>>
>
> Nothing is wrong. We can use <cpu>-w64-mingw32 for GNU triplet and
> make up any debian name for it. It is best if debian name has meaning
> is consistent with other similar arches.

To each his own.  I would think that the debian naming scheme would
want to have as big an intersection as possible with the GNU naming
scheme, but that's just me.  I'll drop the issue.


>>
>>>> That part should eventually just be called "windows", for instance in
>>>> x86_64-w64-windows.

>> No, I was referring to the GNU triplet.  We've talked extensively
>> about the logical collapse into <cpu>-<vendor>-windows, where the
>> vendor key determines if it's from mingw.org, mingw-w64.sf.net, or any
>> other place.
>>
>
> Currently config.sub prefers winnt
>
>        -windowsnt*)
>                os=`echo $os | sed -e 's/windowsnt/winnt/'`
>                ;;
>
> And I don't see config.sub and config.guess recognising <vendor>-windows.

That's because it doesn't.  I was just saying that it's where we
should go in the future.  I have no idea if it will ever happen.

> Creating a patch which will make config.sub and config.guess recognise
> <cpu>-w64-windows, <cpu>-mingw-windows, <cpu>-msys-windows and
> <cpu>-cygwin-windows is IMHO a radical change. Loads of software will
> needs to be patched to recognise vendor tag and not depend on *mingw32
> in their configure scripts.

Well, to transition it properly, you'd define an alias first, then
eventually deprecate and phase out the old one over a long period of
time.

> Would you be willing to provide a patch against config.sub and
> config.guess? Such patch could be integrated into autotools-dev in
> Debian and the rest of software can be patched as described above. It
> will be a painful transition requiring loads of work. I cannot commit
> to doing it.

Can't.  Anonymous contributions aren't accepted.

> I'd rather use windows-<vendor> as Debian OS Name and continue using
> existing Gnu tripplets (-w64-mingw32, -pc-mingw32, *-cygwin, *-msys)
>
>> I don't undrestand the naming structure or purpose of these
>> debianisms, but if you start out fresh using "windows" to signify
>> windows platforms, that seems logically sound.
>>
>
> *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.)

> Are cygwin/msys/mingw people willing to support new triplet naming scheme?

Doubtful.  This is a topic that will inevitably be bikeshedded to
death.  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.  Heck,
getting the "32" part of mingw32 changed to a wildcard (ie, mingw*)
was difficult enough.  It's hard to change the past, and even harder
to change long standing traditions.  However, if it's at all possible,
I fully support a change to triplets that actually make sense.

> I personally would rather work now using existing GNU tripplets (e.g.
> <cpu>-w64-mingw32), call debian arch as win[dows|nt]-<vendor> and
> continue like that. At a later date we can switch the gnu ports to the
> fresh GNU tripplets <cpu>-<vendor>-windows onces cygwin, mingw and
> msys upstream agree to support that. The first transition can happen
> within Debian archive, I just don't want Debian to be the only one to
> have "a different GNU triplet not used by anyone else".

That's probably a good idea, though I doubt anyone will step up and
push the config changes.

Message #105 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Earnie <earnie@users.sourceforge.net>

To: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Cc: mingw64 <mingw-w64-public@lists.sourceforge.net>, Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Fri, 17 Dec 2010 09:45:08 -0500

Dmitrijs Ledkovs wrote:
>
> Fair enough. How is it compiled from source (bootstrap steps if such
> are required)? What compiler do you use to compile MSYS from source?

We handle that manually.  Only MSYS developers will care and it is
documented on www.mingw.org.

> Does it make sense to have msys-compatible precompiled Gtk, Qt etc
> available from Debian-Msys port?

No.

> Can I use compiled for mingw.org libraries in MSYS environment?

Yes, it is the purpose of MSYS.

> Can I use compiled for mingw-w64 libraries in MSYS environment?

Yes, I believe the mingw64 users are using MSYS now.

> Can I use Visual Studio compiled libraries in MSYS environment?

Yes.

MSYS doesn't provide a compiler for general consumption that uses the
MSYS runtime.  Therefore there is no need for a triplet that is publicly
defined.  It does provide a compiler for those who wish to help with
MSYS development and the triplet remains privately defined in that case.

>
> The answers to above questions will tell us whether dpkg should have
msys defined as debian-arch/os.
>

There is no reason for it.

>
> I have read the website. My first understanding that it is
> user-space around Mingw.org runtime which runs on Windows platforms
> to provide user tools to e.g. have a shell capable of running
> autoconf and etc. Thus I thought that we can provide msys as a suite
> of packages compiled as part of Debian-Mingw port. That way you could
> install Debian-Mingw port in a chroot and instead of using
> cross-compiler use e.g. linux + wine + msys = to get msys shell which
> is equivalent to msys shell on Windows.
>
> Hope this makes sense. As you can see I'm not entirely sure what
> MSYS is and what MSYS isn't and where that border lies on the
> mingw-cygwin-w64 spectrum.
>

 The goal of MSYS when I created it was simple, "Provide a tool that
could be used to execute configure and make for the MinGW user." 
Executing uname in MSYS from my Windows XP 32bit system yields a string
that will identify the environment as MINGW32 but that string is
modifiable by the end user with an environment variable named MSYSTEM. 
Currently MSYSTEM is set to MINGW32 but could be set to MINGW64 or MINGW
or CYGWIN or WINDOWS or SOMEOTHERFOOSTRING and the MSYS uname will
report that system.

Earnie

Message #110 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: mingw64 <mingw-w64-public@lists.sourceforge.net>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 606825@bugs.debian.org

Subject: Re: [Mingw-w64-public] dpkg: Please add mingw to ostable and triplettable.

Date: Fri, 17 Dec 2010 17:04:32 +0000

On 17 December 2010 14:45, Earnie <earnie@users.sourceforge.net> wrote:
> Dmitrijs Ledkovs wrote:
>>
>> Fair enough. How is it compiled from source (bootstrap steps if such
>> are required)? What compiler do you use to compile MSYS from source?
>
> We handle that manually.  Only MSYS developers will care and it is
> documented on www.mingw.org.
>

I will try this when I have time =) should be fun.

>> Does it make sense to have msys-compatible precompiled Gtk, Qt etc
>> available from Debian-Msys port?
>
> No.
>

ok.

>> Can I use compiled for mingw.org libraries in MSYS environment?
>
> Yes, it is the purpose of MSYS.
>

ok.

>> Can I use compiled for mingw-w64 libraries in MSYS environment?
>
> Yes, I believe the mingw64 users are using MSYS now.
>

ok.

>> Can I use Visual Studio compiled libraries in MSYS environment?
>
> Yes.
>
> MSYS doesn't provide a compiler for general consumption that uses the
> MSYS runtime.  Therefore there is no need for a triplet that is publicly
> defined.  It does provide a compiler for those who wish to help with
> MSYS development and the triplet remains privately defined in that case.
>

ok.

>>
>> The answers to above questions will tell us whether dpkg should have
> msys defined as debian-arch/os.
>>
>
> There is no reason for it.
>

great.

>>
>> I have read the website. My first understanding that it is
>> user-space around Mingw.org runtime which runs on Windows platforms
>> to provide user tools to e.g. have a shell capable of running
>> autoconf and etc. Thus I thought that we can provide msys as a suite
>> of packages compiled as part of Debian-Mingw port. That way you could
>> install Debian-Mingw port in a chroot and instead of using
>> cross-compiler use e.g. linux + wine + msys = to get msys shell which
>> is equivalent to msys shell on Windows.
>>
>> Hope this makes sense. As you can see I'm not entirely sure what
>> MSYS is and what MSYS isn't and where that border lies on the
>> mingw-cygwin-w64 spectrum.
>>
>
>  The goal of MSYS when I created it was simple, "Provide a tool that
> could be used to execute configure and make for the MinGW user."
> Executing uname in MSYS from my Windows XP 32bit system yields a string
> that will identify the environment as MINGW32 but that string is
> modifiable by the end user with an environment variable named MSYSTEM.
> Currently MSYSTEM is set to MINGW32 but could be set to MINGW64 or MINGW
> or CYGWIN or WINDOWS or SOMEOTHERFOOSTRING and the MSYS uname will
> report that system.
>

ok.

> Earnie
>

I have a better understanding now and I will provide updated patch
with resulting debian/gnu triplets for new review.

Message #115 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: NightStrike <nightstrike@gmail.com>

Cc: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>, 606825@bugs.debian.org, mingw64 <mingw-w64-public@lists.sourceforge.net>

Subject: [PATCH v2] Re: dpkg: Please add mingw to ostable and triplettable.

Date: Sat, 18 Dec 2010 05:32:41 -0600

NightStrike wrote:

> What's wrong with using the existing GNU triplet?

FWIW sorry for setting off this discussion (but thank you --- the
answers have been very helpful to me!).  Luckily you provided a
good example that might help explain the purpose of Debian triplets
later in the thread:

> Dmitrijs Ledkovs wrote:

>> Are cygwin/msys/mingw people willing to support new triplet naming scheme?
[...]
>                        It's hard to change the past, and even harder
> to change long standing traditions.  However, if it's at all possible,
> I fully support a change to triplets that actually make sense.

Having Debian arch names that are not rigidly aligned to GNU triplets
makes such changes easier to weather.

Keep in mind, as I have probably already shown, I am very new to this
(both dpkg and mingw).  So please do not take anything I say as
gospel.

What's in a Debian architecture name?
-------------------------------------

Debian arch names are primarily used to name the Debian machine
architecture[1] for which a package is available.  Each (binary)
package has an Architecture: field naming its machine architecture.

A given dpkg installation only manages packages for one
architecture[2], so where possible it is beneficial to make these
course-grained.

	Example: i486-linux-gnu and i586-linux-gnu get the same
	Debian architecture name ("i386").

Meanwhile they need to be fine-grained enough to ensure
interoperability --- e.g., if package foo depends on package libbar (= 5)
then any build of libbar 5 on the current architecture must be able to
provide the functionality foo needs.

	Example: x86_64-linux-gnu and i686-linux-gnu get
	distinct Debian architecture names ("i386" and "amd64").

[1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
[2] Nowadays there is some work on getting mixed-architecture (e.g.,
i386 + amd64) systems to work well with the packaging system but
that is hard.  So I'll ignore it for the moment. :)

Relationship to GNU triplets
----------------------------

When you build and install dpkg for the first time, its configure
script will run ./config.guess and match the output against ostable
and cputable to figure out which Debian architecture this is.  A given
Debian architecture can correspond to a variety of GNU triplets (as in
the example "i386" above).

When building a Debian package, the build script "debian/rules" has
access[3] to a DEB_HOST_GNU_TYPE variable representing the target
architecture's (preferred) GNU triplet.  This value is generally
passed on to ./configure.

	Example: on i386, DEB_HOST_GNU_TYPE gets set to
	i486-linux-gnu.  When Debian stops supporting 486s with
	mainstream packages, that will presumably change to
	i586-linux-gnu.

Over time it is expected that the matching and preferred GNU triplets
for a given Debian architecture might change.  So mistakes in this
part are not a bit deal.

Debian triplets?
----------------

When building a Debian package, the build script "debian/rules" has
access to DEB_HOST_ARCH_OS, DEB_HOST_GNU_SYSTEM, DEB_HOST_ARCH_CPU,
and DEB_HOST_GNU_CPU variables, which generally get used to work
around architecture-specific bugs ("on such-and-such OS, disable
such-and-such optimization").

	Example: the Debian triplet for the "i386" architecture
	is gnu-linux-i386.  So DEB_HOST_ARCH_OS is linux
	and DEB_HOST_ARCH_CPU is i386.  The "gnu-" part is
	there to distinguish this from uclibc-linux-i386.

Notice that the ABI/libc part of the system name ("gnu" in the
example) is not exposed using the dpkg-architecture script, so build
scripts generally do not depend on it.  That might change some day,
but it would require separating the ABI part from libc part to be
useful, so I wouldn't worry about it.

The case of mingw64
-------------------

mingw-w64-, mingw.org-, and cygwin-built libraries are not
interchangeable from an ABI point of view, so they have to be distinct
Debian architectures.  (Thanks for correcting me multiple times on
this.)  Let's just worry about mingw-w64 for the moment.

The operating system (kernel and user tools) is Windows (except maybe
for cygwin; I don't want to think hard about that).  We can call it

	mingw32, to be consistent with the GNU triplet (confusing!)
	winnt, since I think that's the kernel's name
	windows, for simplicity

windows sounds fine to me.  This includes ReactOS as a special case,
as long as it lives up to its compatibility goals.

The C library is mingw-w64, which could be abbreviated as mingw64 or
w64.  The meaning of mingw64 seems more obvious to me.

No need to tack on an ABI variant in addition to that.  "mingw-w64,
on 32-bit x86" meets the requirements described in "What's in a
Debian architecture name" above, I think.  So how about something
like this?

Dmitrijs, please locally try out whatever variant seems sanest to you
(and I will try to find time to test the cross-toolchain packages).

diff --git a/ostable b/ostable
index 17b7581..672dc13 100644
--- a/ostable
+++ b/ostable
@@ -31,3 +31,4 @@ bsd-openbsd		openbsd			openbsd[^-]*
 sysv-solaris		solaris			solaris[^-]*
 uclibceabi-uclinux	uclinux-uclibceabi	uclinux[^-]*-uclibceabi
 uclibc-uclinux		uclinux-uclibc		uclinux[^-]*(-uclibc.*)?
+mingw64-windows		w64-mingw32		w64-mingw[^-]*
diff --git a/triplettable b/triplettable
index 3e076e2..9cc6e5b 100644
--- a/triplettable
+++ b/triplettable
@@ -20,3 +20,4 @@ bsd-darwin-<cpu>	darwin-<cpu>
 sysv-solaris-<cpu>	solaris-<cpu>
 uclibceabi-uclinux-arm	uclinux-armel
 uclibc-uclinux-<cpu>	uclinux-<cpu>
+mingw64-windows-<cpu>	mingw64-<cpu>

Message #120 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <steve@sk2.org>

To: debian-devel@lists.debian.org

Cc: 606825@bugs.debian.org

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

Date: Fri, 29 Apr 2011 22:44:34 +0200

[Message part 1 (text/plain, inline)]

On Sun, 24 Apr 2011 22:46:40 +0100, Wookey <wookey@wookware.org> wrote:
> +++ Stephen Kitt [2011-04-24 19:14 +0200]:
> > > So I would be opposed to making such a change in policy for the time
> > > being; I think cross-compilers should stick with the traditional
> > > cross-compiler directories and stay away from the multiarch directories
> > > until we have more practical experience with multiarch under our belts
> > > and can make some educated decisions about how we want this to all fit
> > > together.
> > 
> > OK.
> 
> I expect the multiarch paths to replace the 'traditional
> cross-compiling' paths in due course for all target architectures,
> including ones that aren't Debian-suported (i.e currently
> mingw-whatever-you-call-it, avr32, msp430), for both native use and
> cross-compiling. Steve will have to explain to me why we might want to
> use different paths for non-self-hosting arches. It seems to me that
> having one canonical place to look for arch-dependent files is good
> whether you want them for running or for (cross-)building.
> 
> But we do need to proceed carefully in order to get this right, and
> the cross-only arches are a little way down our list of issues :-) I'd
> be interested to hear how you currently do things in mingw world (and
> more importantly what things you want to be able to do) so that we can
> take your needs into account.

I personnally don't speak for upstream, and most of the documentation
available upstream discusses either Windows builds or sysroot-based builds
in /usr/local. There has been a fair amount of discussion in the past though,
including a proposed patch for dpkg (http://bugs.debian.org/606825) and a
specification document on the Debian wiki (http://wiki.debian.org/Mingw-W64
which also has links to other distributions' documentation). I don't
particularly like the sysroot approach, and I believe multiarch would provide
the same functionality, i.e. being able to host at least the headers and
libraries (and link-time DLLs) for cross-compiled libraries.

I see two immediate requirements for MinGW-w64 in Debian:
* being able to build wine-gecko;
* replacing mingw32 and gcc-mingw32.

Looking further, being able to host -dev packages to provide a nice
cross-building environment would be desirable. Being able to host
cross-compiled runtime binaries and DLLs doesn't seem quite so useful to me,
although people using Debian to build installation packages for Windows would
probably disagree.

> I do think that getting the 'win32' arch name and triplet defined in
> dpkg-architecture is stage 1 for you. I thought we'd already done that
> years ago, when this last came up, but obviously not.
> dpkg-architecture already supports 269 options including such
> not-very-useful combinations as uclibc-linux-s390 and solaris-alpha,
> so it really ought to know about the win32 and win64 ABIs. It's
> generally a very simple patch to a few tables in dpkg to add a new arch. 
> 
> Having the mappings between Debian arch name, gnu triplet and multiarch
> path all in one place is vital to making all this stuff work properly.

It is indeed, see above for the existing bug report. I take it people were
perhaps awaiting Dmitrijs' test results before pursuing things; I've built a
patched dpkg and so far the results seem OK, although perhaps not to Adam's
liking since the multiarch directories still end up being MinGW-w64 specific:

% dpkg-architecture -amingw64-amd64
dpkg-architecture: warning: Specified GNU system type x86_64-w64-mingw32 does
not match gcc system type i486-linux-gnu. DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_BUILD_MULTIARCH=i386-linux-gnu
DEB_HOST_ARCH=mingw64-amd64
DEB_HOST_ARCH_OS=windows
DEB_HOST_ARCH_CPU=amd64
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=w64-mingw32
DEB_HOST_GNU_TYPE=x86_64-w64-mingw32
DEB_HOST_MULTIARCH=x86_64-w64-mingw32

% dpkg-architecture -amingw64-i386 
dpkg-architecture: warning: Specified GNU system type i486-w64-mingw32 does not match gcc system type i486-linux-gnu.
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_BUILD_MULTIARCH=i386-linux-gnu
DEB_HOST_ARCH=mingw64-i386
DEB_HOST_ARCH_OS=windows
DEB_HOST_ARCH_CPU=i386
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=i486
DEB_HOST_GNU_SYSTEM=w64-mingw32
DEB_HOST_GNU_TYPE=i486-w64-mingw32
DEB_HOST_MULTIARCH=i386-w64-mingw32

Other distributions and upstream always use i686 for 32-bit MinGW-w64, which
is why I used that too in my current packages. I believe it would still be
possible to have a multiarch using Debian's CPU definitions as above, but
build binutils and gcc with the i686-based triplet so that the commands would
be the same as elsewhere - wouldn't it?

> Please make sure you get the names right - changing them later will be
> very painful. A multiarch name signifies an ABI, as explained in more
> detail here: http://wiki.debian.org/Multiarch/Tuples
> (note that that proposal is no longer current, but does explain what a
> multiarch ABI name is and isn't).

Yes, and I think the above is correct, although I'd like to build test
packages using the above dpkg-architecture (and multiarch-style paths, even
though uploading such packages would have to wait) and see how things go with
the various mingw32-based packages currently in Debian before the change to
dpkg becomes permanent.

> > Would it make any sense then to add an exception for traditional
> > cross-compiler directories, or should cross-compiling library packages
> > simply continue using lintian overrides?
> 
> So you ship packages pre-built to install to the traditional
> cross-compiler dirs (as opposed to making them with dpkg-cross as we
> do on arches where native packages are shipped). Makes sense. I think
> that packages installing to those paths should continue using lintian
> overrides as they are very much 'non-standard'.

OK! I ship pre-built packages in this way because they're also used as
build-dependencies for other packages in Debian, which I gather would be
difficult using dpkg-cross.

> > One last question: without considering multiarch, what is the situation
> > regarding headers? Is the proposal in http://bugs.debian.org/542865 still
> > the intended approach, or is there another solution?
> 
> Headers are deliberately excluded from the scope of
> https://wiki.ubuntu.com/MultiarchSpec in order to shink the problem
> space down into something that it would only take 6 years to implmenet
> :-)
> 
> However the extra bits for cross-compiling using multiarch paths are
> detailed here: https://wiki.ubuntu.com/MultiarchCross and we are
> already implementing that stuff.
> 
> Arch-dependent headers will go into /usr/include/<multiarchpath> and
> arch independent headers will stay in /usr/include. We can also just
> put all headers in /usr/include/<multiarchpath>, and have duplication
> (as we already do for the traditional paths) if the above is
> problematic, however it seems to be working fine for the few packages
> changed so far, so spliting the arch-dependent ones out seems like the
> way to go.

That's what I understood based on Steve's comment and from reading those wiki
pages too.

Thanks for your input,

Stephen

[signature.asc (application/pgp-signature, attachment)]

Message #125 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <xnox@debian.org>

To: 606825@bugs.debian.org

Subject: mingw-w64 triplets/ostable

Date: Wed, 8 Aug 2012 10:30:19 +0100

This is an old bug. But at the debconf multiple people thought it has
been fixed already, while I don't think it was.
One small difference is that in the near future armhf/armel might be a
valid cpu architecture for mingw-w64 port.
The proposal over here http://wiki.debian.org/Mingw-W64 needs updating
to be completely inline with the multi arch spec, since that is now
implemented.

Any updates?

Regards,

Dmitrijs.

Message #130 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Dmitrijs Ledkovs <xnox@debian.org>, 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Wed, 8 Aug 2012 13:01:03 +0200

Hi!

On Wed, 2012-08-08 at 10:30:19 +0100, Dmitrijs Ledkovs wrote:
> This is an old bug. But at the debconf multiple people thought it has
> been fixed already, while I don't think it was.
> One small difference is that in the near future armhf/armel might be a
> valid cpu architecture for mingw-w64 port.
> The proposal over here http://wiki.debian.org/Mingw-W64 needs updating
> to be completely inline with the multi arch spec, since that is now
> implemented.
> 
> Any updates?

Sorry, I thought I had replied but it appears that was not the case,
it was on my radar to come back to it anyway, thanks for the reminder.

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 not sure if it's too late now to consider changing the triplet
upstream, I should probable have brought this up long time ago, but
then it seemed to be pretty settled down already. :/

OTOH, is dpkg buildable and usable at all on mingw-w64 systems? I
understand though that there might be reasons to want the architecture
supported so that cross-building is allowed, but then the request does
not seem pressing, and that's one of the reasons I've not acted on it
before.

thanks,
guillem

Message #135 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <xnox@debian.org>

To: Guillem Jover <guillem@debian.org>

Cc: 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Wed, 8 Aug 2012 12:31:04 +0100

On 8 August 2012 12:01, Guillem Jover <guillem@debian.org> wrote:
> Hi!
>
> On Wed, 2012-08-08 at 10:30:19 +0100, Dmitrijs Ledkovs wrote:
>> This is an old bug. But at the debconf multiple people thought it has
>> been fixed already, while I don't think it was.
>> One small difference is that in the near future armhf/armel might be a
>> valid cpu architecture for mingw-w64 port.
>> The proposal over here http://wiki.debian.org/Mingw-W64 needs updating
>> to be completely inline with the multi arch spec, since that is now
>> implemented.
>>
>> Any updates?
>
> Sorry, I thought I had replied but it appears that was not the case,
> it was on my radar to come back to it anyway, thanks for the reminder.
>
> 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 not sure if it's too late now to consider changing the triplet
> upstream, I should probable have brought this up long time ago, but
> then it seemed to be pretty settled down already. :/
>
> OTOH, is dpkg buildable and usable at all on mingw-w64 systems? I
> understand though that there might be reasons to want the architecture
> supported so that cross-building is allowed, but then the request does
> not seem pressing, and that's one of the reasons I've not acted on it
> before.
>

I have not build dpkg. But perl and most of gnome stack is buildable
and usable. So I don't think there are major blockers for dpkg.
There is no kernel yet (well packaging reactos is out of scope
currently, as in, i am not interested in that), but it is possible to
run the executables with linux kernel + wine.
Yes, the current goals are to:
- provide cross-compilation environment
- run libraries & windows binaries with help of wine
- test packages in approx. windows environment
- provide packages for windows, by wrapping the resulting debs with
nsis installer for example.

It's a bit of a chicken and egg type of situation:
- no dpkg triplet -> no futher porting work
- no further porting work -> no dpkg triplet

Right now I am not asking to upload a fix into debian. I am asking for
the correct triplet that will be accepted, such that if the initial
partial port is sucessful/useful there will not be need to
bootstrap/recompile everything again just because it is later decided
to have a different dpkg triplet.

Regards,
Dmitrijs.

Message #140 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <steve@sk2.org>

To: Guillem Jover <guillem@debian.org>, 606825@bugs.debian.org

Cc: Dmitrijs Ledkovs <xnox@debian.org>

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Sat, 11 Aug 2012 15:34:07 +0200

[Message part 1 (text/plain, inline)]

Hi Guillem,

On Wed, 8 Aug 2012 13:01:03 +0200, Guillem Jover <guillem@debian.org> wrote:
> On Wed, 2012-08-08 at 10:30:19 +0100, Dmitrijs Ledkovs wrote:
> > This is an old bug. But at the debconf multiple people thought it has
> > been fixed already, while I don't think it was.
> > One small difference is that in the near future armhf/armel might be a
> > valid cpu architecture for mingw-w64 port.
> > The proposal over here http://wiki.debian.org/Mingw-W64 needs updating
> > to be completely inline with the multi arch spec, since that is now
> > implemented.
> > 
> > Any updates?
> 
> Sorry, I thought I had replied but it appears that was not the case,
> it was on my radar to come back to it anyway, thanks for the reminder.
> 
> 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 take it you're referring to the "w64" portion, differenciating MinGW-w64
from MinGW? I've been using the attached patch (which I'll explain further
down...) with pretty good results; what would break in dpkg if we wanted
correct support for the vendor? Currently I can specify "mingw64-x86" as an
architecture; wouldn't it be possible to have a "mingw-x86" architecture,
with the appropriate entries in triplettable and ostable, for MinGW support
without any other changes?

> I'm not sure if it's too late now to consider changing the triplet
> upstream, I should probable have brought this up long time ago, but
> then it seemed to be pretty settled down already. :/

I think it is too late, everyone else (MinGW-w64, the many projects using
it, and the various other distributions supporting it) has already switched
to it.

> OTOH, is dpkg buildable and usable at all on mingw-w64 systems? I
> understand though that there might be reasons to want the architecture
> supported so that cross-building is allowed, but then the request does
> not seem pressing, and that's one of the reasons I've not acted on it
> before.

As Dmitrijs explained in his reply, all the MinGW-w64 stuff in Debian is
likely to only ever support cross-compilation, not end up being a full
architecture hosted on Windows. The main reason to have the support in dpkg
is to start building the infrastructure required for a partial architecture,
so we can more easily provide libraries etc. (see for example
http://bugs.debian.org/671437).

As to the attached patch, which is based on Jonathan Nieder's last patch,
I've added tests to deactivate stack protector and relro on Windows, and more
controversially I've added x86 and x64 entries in cputable. The reason for
that is two-fold: first, the "standard" triplet for 32-bit MinGW-w64 is
i686-w64-mingw32, and lots of things break when dpkg-dev says
i486-w64-mingw32 (as happens with the "mingw64-i386" architecture in
Jonathan's patch); second, in the Windows world "x86" is the canonical name
for 32-bit ix86, and "x64" that for 64-bit x86-64.

Regards,

Stephen

[dpkg-mingw-w64.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #145 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Stephen Kitt <steve@sk2.org>

Cc: 606825@bugs.debian.org, Guillem Jover <guillem@debian.org>, Dmitrijs Ledkovs <xnox@debian.org>

Subject: Re: mingw-w64 triplets/ostable

Date: Sat, 11 Aug 2012 07:57:04 -0700

Hi Stephen,

Stephen Kitt wrote:

[...]
> I've added tests to deactivate stack protector and relro on Windows,

Good.  Thanks much for that.

>                                                                      and more
> controversially I've added x86 and x64 entries in cputable.

I think that's a no-go, sorry.  The problem is that after that change
there is no longer one unambiguous Debian arch for each GNU triplet,
which breaks

 - automatic determination of the Debian arch when building dpkg
   for a new system (less important)
 - "dpkg-architecture -t<triplet> -qDEB_HOST_ARCH" (very important)

If the i386 cputype should behave differently for Windows arches, that
could be done more directly, though the use case would have to be
strong.  If we want convenience synonyms for CPU types (with one being
the "real" one, the rest being for user convenience), that could
probably also be done, but I'm not at all convinced it would be worth
the confusion.

>                                                             The reason for
> that is two-fold: first, the "standard" triplet for 32-bit MinGW-w64 is
> i686-w64-mingw32, and lots of things break when dpkg-dev says
> i486-w64-mingw32

Can you spell out this breakage with an example?  Is it about the
names of cross-compiler programs like i686-w64-mingw32-gcc (which
could be addressed with symlinks) or something deeper?

Thanks for testing, and hope that helps,
Jonathan

Message #150 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <steve@sk2.org>

To: 606825@bugs.debian.org

Cc: Jonathan Nieder <jrnieder@gmail.com>

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Sat, 11 Aug 2012 19:57:22 +0200

[Message part 1 (text/plain, inline)]

Hi Jonathan,

On Sat, 11 Aug 2012 07:57:04 -0700, Jonathan Nieder <jrnieder@gmail.com>
wrote:
> Stephen Kitt wrote:
> [...]
> > I've added tests to deactivate stack protector and relro on Windows,
> 
> Good.  Thanks much for that.
> 
> >                                                                      and
> > more controversially I've added x86 and x64 entries in cputable.
> 
> I think that's a no-go, sorry.  The problem is that after that change
> there is no longer one unambiguous Debian arch for each GNU triplet,
> which breaks
> 
>  - automatic determination of the Debian arch when building dpkg
>    for a new system (less important)
>  - "dpkg-architecture -t<triplet> -qDEB_HOST_ARCH" (very important)

Ah right. I didn't expect that change to be the right solution to the
problem...

> If the i386 cputype should behave differently for Windows arches, that
> could be done more directly, though the use case would have to be
> strong.  If we want convenience synonyms for CPU types (with one being
> the "real" one, the rest being for user convenience), that could
> probably also be done, but I'm not at all convinced it would be worth
> the confusion.

OK.

> >                                                             The reason for
> > that is two-fold: first, the "standard" triplet for 32-bit MinGW-w64 is
> > i686-w64-mingw32, and lots of things break when dpkg-dev says
> > i486-w64-mingw32
> 
> Can you spell out this breakage with an example?  Is it about the
> names of cross-compiler programs like i686-w64-mingw32-gcc (which
> could be addressed with symlinks) or something deeper?

In most cases symlinks work fine (that's what I did for the gcc-mingw32
transitional package). I've come across build systems which try to be a bit
too clever though and trip over things such as 

% i486-w64-mingw32-gcc -print-prog-name=ld
/usr/bin/i686-w64-mingw32-ld

- the issue there being that the build system didn't cope with the two
different prefixes. (autoconf comes across this but works perfectly.) I
suppose that's really a bug in the build system, not something which we
should work around. Off the top of my head I can't remember if there were
other issues.

All things considered the simplest way forward is to drop the cputable patch;
at least that way, we'll know that the packages that do build are
well-behaved, and if we end up deciding to add a work-around so that "i386"
means "i686" for MinGW-w64 then we can easily rebuild everything.

Regards,

Stephen

[dpkg-mingw-w64.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #155 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <steve@sk2.org>

To: 606825@bugs.debian.org

Cc: Jonathan Nieder <jrnieder@gmail.com>

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Sat, 11 Aug 2012 21:48:26 +0200

[Message part 1 (text/plain, inline)]

On Sat, Aug 11, 2012 at 07:57:22PM +0200, Stephen Kitt wrote:
> All things considered the simplest way forward is to drop the cputable patch;
                                                   ^just
(and do nothing more)
> at least that way, we'll know that the packages that do build are
> well-behaved, and if we end up deciding to add a work-around so that "i386"
> means "i686" for MinGW-w64 then we can easily rebuild everything.

[signature.asc (application/pgp-signature, inline)]

Message #160 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <xnox@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: Stephen Kitt <steve@sk2.org>, 606825@bugs.debian.org, Guillem Jover <guillem@debian.org>

Subject: Re: mingw-w64 triplets/ostable

Date: Sat, 11 Aug 2012 23:51:38 +0100

On 11 August 2012 15:57, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> controversially I've added x86 and x64 entries in cputable.
>
> I think that's a no-go, sorry.  The problem is that after that change
> there is no longer one unambiguous Debian arch for each GNU triplet,
> which breaks

ditto. this is a no-go.

The arches should use normal debian cputable, e.g. amd64/i386.
What compilers we are going to provide and what optimisation levels
chosen is a different matter.
I am inclined to say that actually only i686 compiler & binaries will
be provided, regardless of how the arch is named. Simply becuase:
(a) we don't know what baseline xp/vista/7/8 actually are
(b) we do know that at i686 mingw-w64 specific features are enabled
(c) we do know that fedora and opensuse are cross-compiling up to
i686, and for the sake of compatibility it would be nice to match.

Apart from that, we are fine.

I'd be happy if the patch would be applied, sans the cputable hunk.
We can debate the complier/cpu level later ;-)

Regards,

Dmitrijs.

Message #165 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Guillem Jover <guillem@debian.org>

Cc: Dmitrijs Ledkovs <xnox@debian.org>, Stephen Kitt <steve@sk2.org>, 606825@bugs.debian.org

Subject: Re: mingw-w64 triplets/ostable

Date: Mon, 13 Aug 2012 09:10:55 -0700

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.ledkov@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

Message #170 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <steve@sk2.org>

To: 606825@bugs.debian.org

Cc: Jonathan Nieder <jrnieder@gmail.com>

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Sun, 19 Aug 2012 16:12:54 +0200

[Message part 1 (text/plain, inline)]

Hi,

On Mon, 13 Aug 2012 09:10:55 -0700, Jonathan Nieder <jrnieder@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.ledkov@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 (application/pgp-signature, attachment)]

Message #177 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <xnox@debian.org>

To: Stephen Kitt <skitt@debian.org>

Cc: "debian-devel@lists.debian.org" <debian-devel@lists.debian.org>, naesten@gmail.com, 606825@bugs.debian.org, Matthias Klose <doko@debian.org>

Subject: Re: jessie release goals

Date: Wed, 8 May 2013 01:35:25 -0700

On 7 May 2013 05:38, Stephen Kitt <skitt@debian.org> wrote:
> Hi Wookey,
>
> On Tue, 7 May 2013 03:04:50 +0100, Wookey <wookey@wookware.org> wrote:
>> (just a decision to leave arch-independent headers in /usr/include and
>> move arch-dependent headers to /usr/include/triplet).
>
> Doesn't this limit us to cross-compiling only across Debian architectures? If
> we go for a full /usr/include/triplet split (in the same way as for
> libraries) we could support cross-compiling to anything with the same
> structure - I'm thinking MinGW-w64 here of course, but I imagine it would
> apply to other targets too, some of which are supported in Debian already
> using the /usr/triplet/include directories.
>

I for one believe that MinGW-w64 should become partial architectures
on debian (both 32 and 64bit variants... and arm?! =) ). Partial as it
would use linux kernel + wine for runtime. Having mingw as an arch
will greatly make it easier to provide an up-to-date archive of deb
package that one would reasonably would want to cross-compile against.
And with some luck and NSIS magic create .exe installers to
redistributed compiled packages to Windows.

I am patiently waiting for bug #606825 dpkg: Please add mingw to
ostable and triplettable. To be fixed. As well there is interest in
developing i686/x86_64-w64-mingw32 [1] port. And doko has also
informally voiced support for such a triplet name at last debconf.

[1] Yes, exactly these i686/x86_64-w64-mingw32 and not other proposed
combinations.

Regards,

Dmitrijs.

Message #182 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <skitt@debian.org>

To: Guillem Jover <guillem@debian.org>, 606825@bugs.debian.org

Cc: Dmitrijs Ledkovs <xnox@debian.org>

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Tue, 3 Dec 2013 23:42:22 +0100

[Message part 1 (text/plain, inline)]

Hi Guillem,

On Sat, Aug 11, 2012 at 03:34:07PM +0200, Stephen Kitt wrote:
> On Wed, 8 Aug 2012 13:01:03 +0200, Guillem Jover <guillem@debian.org> wrote:
> > Sorry, I thought I had replied but it appears that was not the case,
> > it was on my radar to come back to it anyway, thanks for the reminder.
> > 
> > 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 take it you're referring to the "w64" portion, differenciating MinGW-w64
> from MinGW? I've been using the attached patch (which I'll explain further
> down...) with pretty good results; what would break in dpkg if we wanted
> correct support for the vendor? Currently I can specify "mingw64-x86" as an
> architecture; wouldn't it be possible to have a "mingw-x86" architecture,
> with the appropriate entries in triplettable and ostable, for MinGW support
> without any other changes?
> 
> > I'm not sure if it's too late now to consider changing the triplet
> > upstream, I should probable have brought this up long time ago, but
> > then it seemed to be pretty settled down already. :/
> 
> I think it is too late, everyone else (MinGW-w64, the many projects using
> it, and the various other distributions supporting it) has already switched
> to it.
> 
> > OTOH, is dpkg buildable and usable at all on mingw-w64 systems? I
> > understand though that there might be reasons to want the architecture
> > supported so that cross-building is allowed, but then the request does
> > not seem pressing, and that's one of the reasons I've not acted on it
> > before.
> 
> As Dmitrijs explained in his reply, all the MinGW-w64 stuff in Debian is
> likely to only ever support cross-compilation, not end up being a full
> architecture hosted on Windows. The main reason to have the support in dpkg
> is to start building the infrastructure required for a partial architecture,
> so we can more easily provide libraries etc. (see for example
> http://bugs.debian.org/671437).

Is there any chance the attached version could go in? It's against
current git, minus the previous changes to cputable which were wrong.

Now that Debian is increasingly cross-buildable, and with sbuild and
cross-build-essential providing an excellent environment to work in,
it would be great to have mingw-w64 support in dpkg... Unless you have
objections of course!

Regards,

Stephen

[dpkg-mingw-w64.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #187 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <xnox@debian.org>

To: Stephen Kitt <skitt@debian.org>

Cc: Guillem Jover <guillem@debian.org>, 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Wed, 4 Dec 2013 00:00:21 +0000

On 3 December 2013 22:42, Stephen Kitt <skitt@debian.org> wrote:
> Hi Guillem,
>
> On Sat, Aug 11, 2012 at 03:34:07PM +0200, Stephen Kitt wrote:
>> On Wed, 8 Aug 2012 13:01:03 +0200, Guillem Jover <guillem@debian.org> wrote:
>> > Sorry, I thought I had replied but it appears that was not the case,
>> > it was on my radar to come back to it anyway, thanks for the reminder.
>> >
>> > 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 take it you're referring to the "w64" portion, differenciating MinGW-w64
>> from MinGW? I've been using the attached patch (which I'll explain further
>> down...) with pretty good results; what would break in dpkg if we wanted
>> correct support for the vendor? Currently I can specify "mingw64-x86" as an
>> architecture; wouldn't it be possible to have a "mingw-x86" architecture,
>> with the appropriate entries in triplettable and ostable, for MinGW support
>> without any other changes?
>>
>> > I'm not sure if it's too late now to consider changing the triplet
>> > upstream, I should probable have brought this up long time ago, but
>> > then it seemed to be pretty settled down already. :/
>>
>> I think it is too late, everyone else (MinGW-w64, the many projects using
>> it, and the various other distributions supporting it) has already switched
>> to it.
>>
>> > OTOH, is dpkg buildable and usable at all on mingw-w64 systems? I
>> > understand though that there might be reasons to want the architecture
>> > supported so that cross-building is allowed, but then the request does
>> > not seem pressing, and that's one of the reasons I've not acted on it
>> > before.
>>
>> As Dmitrijs explained in his reply, all the MinGW-w64 stuff in Debian is
>> likely to only ever support cross-compilation, not end up being a full
>> architecture hosted on Windows. The main reason to have the support in dpkg
>> is to start building the infrastructure required for a partial architecture,
>> so we can more easily provide libraries etc. (see for example
>> http://bugs.debian.org/671437).
>
> Is there any chance the attached version could go in? It's against
> current git, minus the previous changes to cputable which were wrong.
>
> Now that Debian is increasingly cross-buildable, and with sbuild and
> cross-build-essential providing an excellent environment to work in,
> it would be great to have mingw-w64 support in dpkg... Unless you have
> objections of course!
>

I've carefully reviewed the whole thread and re-reviewed the proposed patch:

* vendor tag is _not_ used to encode API/ABI, GNU_SYSTEM is
"w64-mingw32" - GOOD (agreed by everyone in the thread)
* Debian.pm is correctly patched to disable features, which are not
support - GOOD
* no changes to cputable - GOOD [2]

Another point raised was:
* dpkg ported to w64-mingw32

Actually at the moment that's not needed at all, as at this stage
w64-mingw32 port will be purely cross-compiled and multiarch enabled
only, therefore dpkg is needed for the build_os.
Naturally building as many packages for w64-mingw32 platform as
possible will be a priority.

Please include patch as attached at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606825#182

If there are any other questions / concerns, please raise them now.


[1] if any bugs would arise from that, the porting team will provide
patches / upstream fixes as needed. in practice, we don't expect any
from well-behaved software.
[2] as noted in #611741, a generic implementation is not yet available
to map/select baseline CPU features on a per debian architecture (e.g.
i486 vs i686, ARMv5 vs ARMv6 vs ARMv7hf etc)

Message #192 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Dmitrijs Ledkovs <xnox@debian.org>

Cc: Stephen Kitt <skitt@debian.org>, 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Wed, 4 Dec 2013 09:06:17 +0100

Hi!

On Wed, 2013-12-04 at 00:00:21 +0000, Dmitrijs Ledkovs wrote:
> On 3 December 2013 22:42, Stephen Kitt <skitt@debian.org> wrote:
> > Is there any chance the attached version could go in? It's against
> > current git, minus the previous changes to cputable which were wrong.
> >
> > Now that Debian is increasingly cross-buildable, and with sbuild and
> > cross-build-essential providing an excellent environment to work in,
> > it would be great to have mingw-w64 support in dpkg... Unless you have
> > objections of course!

Ah, nice solution/hack, although it only works because you seem to be
gaming the GNU triplet system. :)

> I've carefully reviewed the whole thread and re-reviewed the proposed patch:
> 
> * vendor tag is _not_ used to encode API/ABI, GNU_SYSTEM is
> "w64-mingw32" - GOOD (agreed by everyone in the thread)

After checking the latest GNU config.git repo, it seems there's no
such system defined (with os=w64-mingw32), only <cpu>-pc-mingw32 (with
os=mingw32). So w64 is still the vendor, being shoehorned here as if
it was part of the os, which does really make sense, because mingw32
or cygwin, etc could be considered the equivalent of glibc on those
operating systems (where it is denoted as -gnu).

I'd happily accept the proposed patch if the config.{guess,sub} pair
where updated upstream in that direction (i.e. support os=w64-mingw32).

> * Debian.pm is correctly patched to disable features, which are not
> support - GOOD
> * no changes to cputable - GOOD [2]

Sure.

> Another point raised was:
> * dpkg ported to w64-mingw32

I just asked OOC, porting dpkg to a Windows environment might not be
possible with the many current Unix assumption dpkg makes.

Thanks,
Guillem

Message #197 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <skitt@debian.org>

To: Guillem Jover <guillem@debian.org>

Cc: Dmitrijs Ledkovs <xnox@debian.org>, 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Sat, 23 Aug 2014 18:40:28 -0700

[Message part 1 (text/plain, inline)]

On Wed, 4 Dec 2013 09:06:17 +0100, Guillem Jover <guillem@debian.org> wrote:
> On Wed, 2013-12-04 at 00:00:21 +0000, Dmitrijs Ledkovs wrote:
> > I've carefully reviewed the whole thread and re-reviewed the proposed
> > patch:
> > 
> > * vendor tag is _not_ used to encode API/ABI, GNU_SYSTEM is
> > "w64-mingw32" - GOOD (agreed by everyone in the thread)
> 
> After checking the latest GNU config.git repo, it seems there's no
> such system defined (with os=w64-mingw32), only <cpu>-pc-mingw32 (with
> os=mingw32). So w64 is still the vendor, being shoehorned here as if
> it was part of the os, which does really make sense, because mingw32
> or cygwin, etc could be considered the equivalent of glibc on those
> operating systems (where it is denoted as -gnu).
> 
> I'd happily accept the proposed patch if the config.{guess,sub} pair
> where updated upstream in that direction (i.e. support os=w64-mingw32).

OK, so I've been working on this off-and-on for the last few months, and I
now understand why upstream went for this "cheat"...

Come to think about it though, I'm not 100% sure I understand what you're
asking. Do you want
	config.sub i686-w64-mingw32
to canonicalise to i686-pc-w64-mingw32 (cpu=i686, vendor=pc, os=w64-mingw32),
or do you want
	config.sub i686-pc-w64-mingw32
to canonicalise to i686-w64-mingw32?

The version I've been investigating is the former, where the canonical form
is i686-pc-w64-mingw32 (or x86_64-pc-w64-mingw32). It's doable, but it
requires at least:
* updating libtool so it knows about os=*mingw32* (and not just os=mingw32*)
* updating gcc likewise
* once the above are done, adding os=w64-mingw32 to config (we need to wait
  until libtool and gcc are updated to avoid instantly breaking anything
  building for mingw-w64)
* fixing any downstream breakage (and there will be a fair amount)...

That's just the technical side of things. I'm not sure how easy it would be
to convince the various upstreams and downstreams (e.g. Fedora, OpenSuSE,
and the many projects using MinGW-w64) of the necessity of all this; just
as an example the gcc patch is over 5000 lines so I imagine people could be
reluctant to accept it (OK, many of those lines are auto-generated, but
still).

Before I embark on trying to discuss this with the various upstreams, could
you clarify your exact requirements for getting this into dpkg?

Thanks in advance,

Stephen

[signature.asc (application/pgp-signature, attachment)]

Message #202 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Stephen Kitt <skitt@debian.org>, 606825@bugs.debian.org

Cc: Dmitrijs Ledkovs <xnox@debian.org>

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Sat, 30 Aug 2014 15:51:12 +0200

Hi!

On Sat, 2014-08-23 at 18:40:28 -0700, Stephen Kitt wrote:
> On Wed, 4 Dec 2013 09:06:17 +0100, Guillem Jover <guillem@debian.org> wrote:
> > On Wed, 2013-12-04 at 00:00:21 +0000, Dmitrijs Ledkovs wrote:
> > > I've carefully reviewed the whole thread and re-reviewed the proposed
> > > patch:
> > > 
> > > * vendor tag is _not_ used to encode API/ABI, GNU_SYSTEM is
> > > "w64-mingw32" - GOOD (agreed by everyone in the thread)
> > 
> > After checking the latest GNU config.git repo, it seems there's no
> > such system defined (with os=w64-mingw32), only <cpu>-pc-mingw32 (with
> > os=mingw32). So w64 is still the vendor, being shoehorned here as if
> > it was part of the os, which does really make sense, because mingw32
> > or cygwin, etc could be considered the equivalent of glibc on those
> > operating systems (where it is denoted as -gnu).
> > 
> > I'd happily accept the proposed patch if the config.{guess,sub} pair
> > where updated upstream in that direction (i.e. support os=w64-mingw32).

> OK, so I've been working on this off-and-on for the last few months, and I
> now understand why upstream went for this "cheat"...
>
> Come to think about it though, I'm not 100% sure I understand what you're
> asking. Do you want
> 	config.sub i686-w64-mingw32
> to canonicalise to i686-pc-w64-mingw32 (cpu=i686, vendor=pc, os=w64-mingw32),

Yes, I was talking about something like this one. But see below, seems
things might have changed (for the better)?

> The version I've been investigating is the former, where the canonical form
> is i686-pc-w64-mingw32 (or x86_64-pc-w64-mingw32). It's doable, but it
> requires at least:
> * updating libtool so it knows about os=*mingw32* (and not just os=mingw32*)
> * updating gcc likewise
> * once the above are done, adding os=w64-mingw32 to config (we need to wait
>   until libtool and gcc are updated to avoid instantly breaking anything
>   building for mingw-w64)
> * fixing any downstream breakage (and there will be a fair amount)...

I don't think that diverges much from what one usually needs to do for
a new port, which this really was, obviously saying that from the comfort
of not being the one who's going to be doing the work… :/.

> That's just the technical side of things. I'm not sure how easy it would be
> to convince the various upstreams and downstreams (e.g. Fedora, OpenSuSE,
> and the many projects using MinGW-w64) of the necessity of all this; just
> as an example the gcc patch is over 5000 lines so I imagine people could be
> reluctant to accept it (OK, many of those lines are auto-generated, but
> still).
> 
> Before I embark on trying to discuss this with the various upstreams, could
> you clarify your exact requirements for getting this into dpkg?

As metioned before, the prevalent assumption in dpkg-dev and in most
of the Debian packaging and system is that the vendor is irrelevant.
And you should really think about the vendor as part of the machine,
and to be the hw manufacturer, not the one providing the software. It
does not usually get exposed anywhere, not even on DEB_HOST_GNU_TYPE
style variables and we do not have DEB_HOST_GNU_VENDOR or
_GNU_MANUFACTURER style ones either for example.

In addition the current triplet is also just wrong, I get the impression
that it was concocted to get a free ride and to avoid what might end up
being needed to be done anyway, a “cheat” as you put it, and I've to say
I've been a bit annoyed by it because it “perverts” the GNU triplet
system and moves the burden to someone else, which means it ends up
not being free at all.

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?

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).

Thanks,
Guillem

Message #207 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <skitt@debian.org>

To: Guillem Jover <guillem@debian.org>

Cc: 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Tue, 9 Sep 2014 23:28:10 +0200

[Message part 1 (text/plain, inline)]

Hi Guillem,

(I'm dropping Dimitri from the cc since he's no longer interested in this!)

On Sat, 30 Aug 2014 15:51:12 +0200, Guillem Jover <guillem@debian.org> wrote:
> On Sat, 2014-08-23 at 18:40:28 -0700, Stephen Kitt wrote:
> > OK, so I've been working on this off-and-on for the last few months, and I
> > now understand why upstream went for this "cheat"...
> >
> > Come to think about it though, I'm not 100% sure I understand what you're
> > asking. Do you want
> > 	config.sub i686-w64-mingw32
> > to canonicalise to i686-pc-w64-mingw32 (cpu=i686, vendor=pc,
> > os=w64-mingw32),
> 
> Yes, I was talking about something like this one. But see below, seems
> things might have changed (for the better)?
> 
> > The version I've been investigating is the former, where the canonical
> > form is i686-pc-w64-mingw32 (or x86_64-pc-w64-mingw32). It's doable, but
> > it requires at least:
> > * updating libtool so it knows about os=*mingw32* (and not just
> > os=mingw32*)
> > * updating gcc likewise
> > * once the above are done, adding os=w64-mingw32 to config (we need to
> > wait until libtool and gcc are updated to avoid instantly breaking
> > anything building for mingw-w64)
> > * fixing any downstream breakage (and there will be a fair amount)...
> 
> I don't think that diverges much from what one usually needs to do for
> a new port, which this really was, obviously saying that from the comfort
> of not being the one who's going to be doing the work… :/.

OK, at least that's clear, and it's nice to know you feel my pain too ;-).

> > That's just the technical side of things. I'm not sure how easy it would
> > be to convince the various upstreams and downstreams (e.g. Fedora,
> > OpenSuSE, and the many projects using MinGW-w64) of the necessity of all
> > this; just as an example the gcc patch is over 5000 lines so I imagine
> > people could be reluctant to accept it (OK, many of those lines are
> > auto-generated, but still).
> > 
> > Before I embark on trying to discuss this with the various upstreams,
> > could you clarify your exact requirements for getting this into dpkg?
> 
> As metioned before, the prevalent assumption in dpkg-dev and in most
> of the Debian packaging and system is that the vendor is irrelevant.
> And you should really think about the vendor as part of the machine,
> and to be the hw manufacturer, not the one providing the software. It
> does not usually get exposed anywhere, not even on DEB_HOST_GNU_TYPE
> style variables and we do not have DEB_HOST_GNU_VENDOR or
> _GNU_MANUFACTURER style ones either for example.

That makes perfect sense, thanks. I suppose it's the same reasoning which
gives the usual "shortcut" armhf triplet "arm-linux-gnueabihf" which is really
"arm-unknown-linux-gnueabihf".

> In addition the current triplet is also just wrong, I get the impression
> that it was concocted to get a free ride and to avoid what might end up
> being needed to be done anyway, a “cheat” as you put it, and I've to say
> I've been a bit annoyed by it because it “perverts” the GNU triplet
> system and moves the burden to someone else, which means it ends up
> not being free at all.

Yes, that's what I meant by saying that I now understood why upstream went
down this path!

> 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; hence

$ /usr/share/misc/config.sub mingw32
i686-pc-mingw32
$ /usr/share/misc/config.sub mingw64
x86_64-pc-mingw64

I'll take it up with MinGW-w64 upstream though and see what they make of it.

> 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?

I'd rather do the work required to get something supported properly in Debian
and by upstream...

Regards,

Stephen

[signature.asc (application/pgp-signature, attachment)]

Message #212 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Stephen Kitt <skitt@debian.org>, 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Mon, 15 Sep 2014 17:46:03 +0200

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 <guillem@debian.org> 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.

> > 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

Message #219 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Joe Nahmias <joe@nahmias.net>

To: Guillem Jover <guillem@debian.org>, Stephen Kitt <skitt@debian.org>, 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Thu, 26 Dec 2019 22:20:45 -0500

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 <guillem@debian.org> 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

Message #224 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <skitt@debian.org>

To: Joe Nahmias <joe@nahmias.net>

Cc: Guillem Jover <guillem@debian.org>, 606825@bugs.debian.org

Subject: Re: Bug#606825: mingw-w64 triplets/ostable

Date: Fri, 27 Dec 2019 14:57:27 +0100

[Message part 1 (text/plain, inline)]

Hi Joe,

On Thu, 26 Dec 2019 22:20:45 -0500, Joe Nahmias <joe@nahmias.net> wrote:
> 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?

We still need to figure out how to handle the triplet. There are multiple
goals, from end users’ perspectives, some conflicting:

* provide a Windows cross-compiler with a good selection of libraries, within
  Debian, so that it’s easy to build Windows programs and their installers;
* provide a Windows cross-compiler which integrates well with
  externally-provided libraries;
* provide a Windows cross-compiler fulfilling the requirements of other
  Debian packages (this is what got me started down this path: Wine Gecko,
  Wine Mono, Debian installer components, etc.).

The main sticking point in this bug is the choice of target triplet. The
current situation is as follows:

* MinGW-w64 upstream have settled on <cpu>-w64-mingw32, distinct from MinGW’s
  <cpu>-pc-mingw32;
* GCC supports both, and uses the -w64- part to distinguish between “plain”
  MinGW support and MinGW-w64 support;
* the Windows cross-compiling community at large uses <cpu>-w64-mingw32.

(Note that the GCC docs claim that -pc-mingw32 is used for MinGW-w64, but
that’s incorrect.)

Guillem has explained in previous emails why -w64-mingw32 causes issues in
Debian. There are other problems with the triplet which haven’t been
mentioned so far: mainly, that the same triplet is used for different
compiler configurations which effectively result in different ABIs. For
32-bit targets, there’s DW2 v. SJLJ (64-bit only used SEH); for all targets,
there’s POSIX v. Win32 threads; a more recent development is support for UCRT
instead of MSVCRT.

I see two main questions to answer:

* for Debian multiarch, what triplet(s) make most sense?
* ignoring multiarch, how can we provide a useful cross-compiler which
  supports all the target setups users are likely to need? -m options via
  spec files?

I’ve been working on the latter mostly. I’m fairly busy just now so I won’t
necessarily be all that responsive, but I’m interested in your thoughts on
the subject.

Regards,

Stephen

[Message part 2 (application/pgp-signature, inline)]

Message #229 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Stephen Kitt <skitt@debian.org>, 606825@bugs.debian.org

Cc: Joe Nahmias <joe@nahmias.net>, Guillem Jover <guillem@debian.org>

Subject: Re: mingw-w64 triplets/ostable

Date: Mon, 30 Dec 2019 10:33:17 -0800

Hi Stephen,

Stephen Kitt wrote:

> We still need to figure out how to handle the triplet. There are multiple
> goals, from end users’ perspectives, some conflicting:
>
> * provide a Windows cross-compiler with a good selection of libraries, within
>   Debian, so that it’s easy to build Windows programs and their installers;
> * provide a Windows cross-compiler which integrates well with
>   externally-provided libraries;
> * provide a Windows cross-compiler fulfilling the requirements of other
>   Debian packages (this is what got me started down this path: Wine Gecko,
>   Wine Mono, Debian installer components, etc.).

Thanks for this breakdown.  The first sounds like (partial) architecture
bringup, the second is an additional compatibility goal, and the third
could be achieved using multilib but is simpler with multiarch.

If I label these as (a), (b), and (c), then which of these goals is
important to you?  What about others in mingw-w64 and related
projects?

 a. provide a Windows cross-development environment useful for building
    non-trivial programs and their installers

 b. provide a Windows cross-compiler that integrates well with
    existing externally provided libraries

 c. provide a Windows cross-compiler sufficient to meet the needs of
    Debian packages such as wine, mono, and so on

For bringing up a Debian arch, I would expect (a) and (c) to be
important and (b) to not be important at all.  On the other hand, I
wouldn't be surprised if some other people have (b) as a goal, and if
it's easy to get for free then we shouldn't forget about it. :)

[...]
> Guillem has explained in previous emails why -w64-mingw32 causes issues in
> Debian.

Yes, and not only Debian: any system that relies on the notion of ABI
will run into the same problems.

>         There are other problems with the triplet which haven’t been
> mentioned so far: mainly, that the same triplet is used for different
> compiler configurations which effectively result in different ABIs. For
> 32-bit targets, there’s DW2 v. SJLJ (64-bit only used SEH); for all targets,
> there’s POSIX v. Win32 threads; a more recent development is support for UCRT
> instead of MSVCRT.

Yes.

> I see two main questions to answer:

For architecture bringup, you left out the most important question of
all: what ABI do you want to use for the new architecture?

Given a choice of ABI and how to name it, it's possible to make
progress within Debian without waiting for upstream.  We'd want to
keep upstream involved every step of the way and to benefit from their
expertise, but part of the magic of having a single project for an
entire operating system distribution is that in the worst case we
*can* go it alone.

In fact I doubt that would be necessary.  Upstream has similar goals.
Picking a triplet without coordinating with upstream would be highly
dangerous unless we stick "debian" in there somewhere (yuck).  I only
mention it as a way to avoid forgetting our responsibilities: if we
aren't able to find the right way to serve these users, in the end we
have no one to blame but ourselves.

Thanks,
Jonathan

Message #234 received at 606825@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: 606825@bugs.debian.org

Subject: Bug#606825: mingw triplets/ostable

Date: Thu, 13 Jul 2023 19:02:57 +0200

Hi!

Just noticed this change to the GNU config project which I wanted to
add a reference here:

  https://git.savannah.gnu.org/cgit/config.git/commit/?id=91f6a7f616b161c25ba2001861a40e662e18c4ad

Thanks,
Guillem

Send a report that this bug log contains spam.