Hi Jonathan, On Sat, 11 Aug 2012 07:57:04 -0700, Jonathan Nieder <jrnie...@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
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
