Hi Guillem, On Wed, 8 Aug 2012 13:01:03 +0200, Guillem Jover <guil...@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
diff --git a/cputable b/cputable
index 28630f0..70e5a15 100644
--- a/cputable
+++ b/cputable
@@ -39,3 +39,5 @@ sh4 sh4 sh4 32 little
sh4eb sh4eb sh4eb 32 big
sparc sparc sparc 32 big
sparc64 sparc64 sparc64 64 big
+x86 i686 (i[3456]86|pentium) 32 little
+x64 x86_64 x86_64 64 little
diff --git a/ostable b/ostable
index 3348014..eea6c20 100644
--- a/ostable
+++ b/ostable
@@ -34,3 +34,4 @@ sysv-solaris solaris solaris[^-]*
uclibceabi-uclinux uclinux-uclibceabi uclinux[^-]*-uclibceabi
uclibc-uclinux uclinux-uclibc uclinux[^-]*(-uclibc.*)?
tos-mint mint mint[^-]*
+mingw64-windows w64-mingw32 w64-mingw32[^-]*
diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index 72d9ef0..df2d24f 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -127,15 +127,17 @@ sub add_hardening_flags {
# (#574716).
$use_feature{"pie"} = 0;
}
- if ($cpu =~ /^(ia64|alpha|mips|mipsel|hppa)$/ or $arch eq "arm") {
+ if ($cpu =~ /^(ia64|alpha|mips|mipsel|hppa)$/ or $arch eq "arm" or $os eq "windows") {
# Stack protector disabled on ia64, alpha, mips, mipsel, hppa.
# "warning: -fstack-protector not supported for this target"
# Stack protector disabled on arm (ok on armel).
# compiler supports it incorrectly (leads to SEGV)
+ # Stack protector disabled on Windows (requires glibc).
$use_feature{"stackprotector"} = 0;
}
- if ($cpu =~ /^(ia64|hppa|avr32)$/) {
+ if ($cpu =~ /^(ia64|hppa|avr32)$/ or $os eq "windows") {
# relro not implemented on ia64, hppa, avr32.
+ # relro not implemented on Windows.
$use_feature{"relro"} = 0;
}
diff --git a/triplettable b/triplettable
index 11f8a54..b2b43b3 100644
--- a/triplettable
+++ b/triplettable
@@ -23,3 +23,4 @@ sysv-solaris-<cpu> solaris-<cpu>
uclibceabi-uclinux-arm uclinux-armel
uclibc-uclinux-<cpu> uclinux-<cpu>
tos-mint-m68k mint-m68k
+mingw64-windows-<cpu> mingw64-<cpu>
signature.asc
Description: PGP signature
