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

version graph

Package: dpkg; Maintainer for dpkg is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg is src:dpkg.

Reported by: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

Date: Sun, 12 Dec 2010 00:39:04 UTC

Severity: wishlist

Tags: patch

Found in version dpkg/1.15.8.6

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sun, 12 Dec 2010 00:39:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 12 Dec 2010 00:39:07 GMT) Full text and rfc822 format available.

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

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


Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sun, 12 Dec 2010 01:33:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 12 Dec 2010 01:33:08 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sun, 12 Dec 2010 10:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 12 Dec 2010 10:00:03 GMT) Full text and rfc822 format available.

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

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Mon, 13 Dec 2010 23:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 13 Dec 2010 23:27:03 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 00:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 00:30:03 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 12:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to NightStrike <nightstrike@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 12:57:04 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 13:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andy Koppe <andy.koppe@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 13:24:03 GMT) Full text and rfc822 format available.

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

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 14:39:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to JonY <jon_y@users.sourceforge.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 14:39:07 GMT) Full text and rfc822 format available.

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

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 16:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 16:42:03 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 16:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 16:45:03 GMT) Full text and rfc822 format available.

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

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

???




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 16:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ruben Van Boxem <vanboxem.ruben@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 16:51:03 GMT) Full text and rfc822 format available.

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

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 16:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andy Koppe <andy.koppe@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 16:57:03 GMT) Full text and rfc822 format available.

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

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 14 Dec 2010 23:48:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to JonY <jon_y@users.sourceforge.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 14 Dec 2010 23:48:07 GMT) Full text and rfc822 format available.

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

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 15 Dec 2010 13:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to NightStrike <nightstrike@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 15 Dec 2010 13:39:03 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 15 Dec 2010 16:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 15 Dec 2010 16:12:06 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 15 Dec 2010 23:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to JonY <jon_y@users.sourceforge.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 15 Dec 2010 23:39:03 GMT) Full text and rfc822 format available.

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

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Thu, 16 Dec 2010 14:21:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to mingw64 <mingw-w64-public@lists.sourceforge.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 16 Dec 2010 14:21:08 GMT) Full text and rfc822 format available.

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

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Thu, 16 Dec 2010 17:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 16 Dec 2010 17:00:03 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Thu, 16 Dec 2010 17:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 16 Dec 2010 17:00:04 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Thu, 16 Dec 2010 19:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to NightStrike <nightstrike@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 16 Dec 2010 19:21:05 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Fri, 17 Dec 2010 14:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to mingw64 <mingw-w64-public@lists.sourceforge.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 17 Dec 2010 14:48:03 GMT) Full text and rfc822 format available.

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

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Fri, 17 Dec 2010 17:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 17 Dec 2010 17:09:06 GMT) Full text and rfc822 format available.

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

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.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sat, 18 Dec 2010 11:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 18 Dec 2010 11:36:03 GMT) Full text and rfc822 format available.

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

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>




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Fri, 29 Apr 2011 20:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Kitt <steve@sk2.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 29 Apr 2011 20:48:03 GMT) Full text and rfc822 format available.

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

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 08 Aug 2012 09:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <xnox@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 08 Aug 2012 09:33:03 GMT) Full text and rfc822 format available.

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

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.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 08 Aug 2012 11:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 08 Aug 2012 11:03:03 GMT) Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 08 Aug 2012 11:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <xnox@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 08 Aug 2012 11:33:03 GMT) Full text and rfc822 format available.

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

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.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sat, 11 Aug 2012 13:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Kitt <steve@sk2.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 11 Aug 2012 13:39:03 GMT) Full text and rfc822 format available.

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

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sat, 11 Aug 2012 14:57:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 11 Aug 2012 14:57:16 GMT) Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sat, 11 Aug 2012 18:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Kitt <steve@sk2.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 11 Aug 2012 18:00:03 GMT) Full text and rfc822 format available.

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

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sat, 11 Aug 2012 19:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Kitt <steve@sk2.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 11 Aug 2012 19:51:03 GMT) Full text and rfc822 format available.

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

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sat, 11 Aug 2012 22:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <xnox@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 11 Aug 2012 22:54:03 GMT) Full text and rfc822 format available.

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

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.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Mon, 13 Aug 2012 16:12:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 13 Aug 2012 16:12:09 GMT) Full text and rfc822 format available.

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

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



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Sun, 19 Aug 2012 14:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Kitt <steve@sk2.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 19 Aug 2012 14:15:03 GMT) Full text and rfc822 format available.

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

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

Added indication that bug 606825 blocks 671437 Request was from Samuel Bronson <naesten@gmail.com> to control@bugs.debian.org. (Sun, 02 Dec 2012 19:42:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 08 May 2013 08:36:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <xnox@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 08 May 2013 08:36:08 GMT) Full text and rfc822 format available.

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

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.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Tue, 03 Dec 2013 22:45:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Kitt <skitt@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 03 Dec 2013 22:45:14 GMT) Full text and rfc822 format available.

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

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 04 Dec 2013 00:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitrijs Ledkovs <xnox@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 04 Dec 2013 00:03:04 GMT) Full text and rfc822 format available.

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

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)



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#606825; Package dpkg. (Wed, 04 Dec 2013 08:09:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 04 Dec 2013 08:09:10 GMT) Full text and rfc822 format available.

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

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



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 15:28:56 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.