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.
Hi, Some uninformed reactions. Dmitrijs Ledkovs wrote: 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!) So the value in the "GNU name" column is correct.
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 =) Thank you for shedding some more lights of what ABI/OS parts should mean! "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 ----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. 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.
Dmitrijs Ledkovs wrote: That answers my main question. Then I suppose: 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? Ah, interesting. Thanks again. Others wiser than I am can presumably take it from here.
----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 All four of the above triplets make sense and are "in the wild out there not packaged in Debian" Yes. For i386 and amd64 Debian cpu's. Shall I provide an updated patch against dpkg? With regards, Dmitrijs.
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.
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.
$ 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. 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. 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.
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 ???
2010/12/14 Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com> 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. 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).
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.
So.... debian renames all of the existing GNU triplets that are standardized? Why is that at all necessary? What's wrong with using the existing 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. Yes. Binaries compiled with mingw-w64 toolchains, even those that target 32-bit, are not guaranteed to be compatible with those of mingw.org. 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.
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)
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.
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)
*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".
Ok.
Ok.
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.
Dmitrijs Ledkovs wrote: 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
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. 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. With regards, Dmitrijs.
What is GNU triplet for ReactOS? Should we define a separate Debian-arch/os for ReactOS? Regards, Dmitrijs.
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'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. 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. Can't. Anonymous contributions aren't accepted. 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.) 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. That's probably a good idea, though I doubt anyone will step up and push the config changes.
Dmitrijs Ledkovs wrote: We handle that manually. Only MSYS developers will care and it is documented on www.mingw.org. No. Yes, it is the purpose of MSYS. Yes, I believe the mingw64 users are using MSYS now. 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. msys defined as debian-arch/os. There is no reason for it. 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
I will try this when I have time =) should be fun. ok. ok. ok. ok. great. ok. I have a better understanding now and I will provide updated patch with resulting debian/gnu triplets for new review.
NightStrike wrote:
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:
[...]
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>
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. 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? 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. 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. That's what I understood based on Steve's comment and from reading those wiki pages too. Thanks for your input, Stephen
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.
Hi! 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
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.
Hi Guillem, 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 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. 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
Hi Stephen, Stephen Kitt wrote: [...] Good. Thanks much for that. 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. 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
Hi Jonathan, Ah right. I didn't expect that change to be the right solution to the problem... OK. 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
^just
(and do nothing more)
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.
Hi, Guillem Jover wrote: 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
Hi, On Mon, 13 Aug 2012 09:10:55 -0700, Jonathan Nieder <jrnieder@gmail.com> wrote: 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. This is pretty much upstream's general opinion as far as changing the triplet is concerned... (Although I haven't asked recently.) That works fine. 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. 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
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.
Hi Guillem, 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
* 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)
Hi!
Ah, nice solution/hack, although it only works because you seem to be
gaming the GNU triplet system. :)
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).
Sure.
I just asked OOC, porting dpkg to a Windows environment might not be
possible with the many current Unix assumption dpkg makes.
Thanks,
Guillem
OK, so I've been working on this off-and-on for the last few months, and I now understand why upstream went for this "cheat"... Come to think about it though, I'm not 100% sure I understand what you're asking. Do you want config.sub i686-w64-mingw32 to canonicalise to i686-pc-w64-mingw32 (cpu=i686, vendor=pc, os=w64-mingw32), or do you want config.sub i686-pc-w64-mingw32 to canonicalise to i686-w64-mingw32? The version I've been investigating is the former, where the canonical form is i686-pc-w64-mingw32 (or x86_64-pc-w64-mingw32). It's doable, but it requires at least: * updating libtool so it knows about os=*mingw32* (and not just os=mingw32*) * updating gcc likewise * once the above are done, adding os=w64-mingw32 to config (we need to wait until libtool and gcc are updated to avoid instantly breaking anything building for mingw-w64) * fixing any downstream breakage (and there will be a fair amount)... That's just the technical side of things. I'm not sure how easy it would be to convince the various upstreams and downstreams (e.g. Fedora, OpenSuSE, and the many projects using MinGW-w64) of the necessity of all this; just as an example the gcc patch is over 5000 lines so I imagine people could be reluctant to accept it (OK, many of those lines are auto-generated, but still). Before I embark on trying to discuss this with the various upstreams, could you clarify your exact requirements for getting this into dpkg? Thanks in advance, Stephen
Hi! Yes, I was talking about something like this one. But see below, seems things might have changed (for the better)? I don't think that diverges much from what one usually needs to do for a new port, which this really was, obviously saying that from the comfort of not being the one who's going to be doing the work… :/. As metioned before, the prevalent assumption in dpkg-dev and in most of the Debian packaging and system is that the vendor is irrelevant. And you should really think about the vendor as part of the machine, and to be the hw manufacturer, not the one providing the software. It does not usually get exposed anywhere, not even on DEB_HOST_GNU_TYPE style variables and we do not have DEB_HOST_GNU_VENDOR or _GNU_MANUFACTURER style ones either for example. In addition the current triplet is also just wrong, I get the impression that it was concocted to get a free ride and to avoid what might end up being needed to be done anyway, a “cheat” as you put it, and I've to say I've been a bit annoyed by it because it “perverts” the GNU triplet system and moves the burden to someone else, which means it ends up not being free at all. But I just noticed that a proper triplet was accepted in the config.git repo around 2012 (commit f16804b79ee5a23a9994a1cdc760cd9ba813148a), this is what config.sub has to say: $ /usr/share/misc/config.sub mingw64 x86_64-pc-mingw64 $ /usr/share/misc/config.sub x86_64-mingw64 x86_64-pc-mingw64 $ /usr/share/misc/config.sub i686-mingw64 i686-pc-mingw64 So, just one thought, if you are going to end up having to do the work that would be required to add support for what amounts to the equivalent of a new triplet, you could as well use a proper triplet, like the one above? In the end it seems to me that as long as the triplet is officially supported by config.sub/guess the rest of software should just follow suit, which as mentioned before is what needs to be done for each and every new architecture anyway. What might be more time consuming is hunting down and updating the rest of the affected packages in Debian, but given that this has been thought to be a partial architecture from the beginning it should not amount to so many packages (in contrast to a full fledged architecture, that is). Thanks, Guillem
Hi Guillem, (I'm dropping Dimitri from the cc since he's no longer interested in this!) OK, at least that's clear, and it's nice to know you feel my pain too ;-). That makes perfect sense, thanks. I suppose it's the same reasoning which gives the usual "shortcut" armhf triplet "arm-linux-gnueabihf" which is really "arm-unknown-linux-gnueabihf". Yes, that's what I meant by saying that I now understood why upstream went down this path! That triplet was actually added by the MinGW project, not the MinGW-w64 project, and is intended for their putative 64-bit support, whenever that appears; hence $ /usr/share/misc/config.sub mingw32 i686-pc-mingw32 $ /usr/share/misc/config.sub mingw64 x86_64-pc-mingw64 I'll take it up with MinGW-w64 upstream though and see what they make of it. I think what will be time-consuming is getting the various required patches into the various upstream projects; there are very few affected packages in Debian. Unless you mean we should just go our own way, regardless of what upstream thinks, and use the mingw64 which is already in config.sub and patch whatever breaks? I'd rather do the work required to get something supported properly in Debian and by upstream... Regards, Stephen
Hi! Oh wow, even more confusion to the already confusing current situation. I assume we cannot expect the mingw-w64 and the mingw64 ports to be ABI compatible? :( Thanks, that might help. Well, not really if that would mean making the situation even worse by conflating what might end up being upstream projects tripping over each other's triplets. (Sorry, this was not clear from the aforementioned commit.) Sure. Thanks, Guillem
Greetings!
I recently became interested in cross-compiling software from Debian to
Windows. To my delight, I found the gcc-mingw-w64 & mingw-w64-tools
packages already in Debian (thanks Stephen!). However, I see that they
are using a workaround of a /usr/${triplet}/ path, rather than multi-arch.
Then found and read through this bug which hasn't seen an update in 5+
years :( Meanwhile, the Windows world has changed quite a bit in that
time, with Windows 10 being released in 2015, and Windows 7 due to go
EOL on 2020-01-14.
So, how can I best help the effort to get a proper multi-arch
infrastructure in Debian appropriate from cross-building using mingw-w64?
Did this conversation happen? Was there any result?
Thanks,
--Joe
Hi Joe, We still need to figure out how to handle the triplet. There are multiple goals, from end users’ perspectives, some conflicting: * provide a Windows cross-compiler with a good selection of libraries, within Debian, so that it’s easy to build Windows programs and their installers; * provide a Windows cross-compiler which integrates well with externally-provided libraries; * provide a Windows cross-compiler fulfilling the requirements of other Debian packages (this is what got me started down this path: Wine Gecko, Wine Mono, Debian installer components, etc.). The main sticking point in this bug is the choice of target triplet. The current situation is as follows: * MinGW-w64 upstream have settled on <cpu>-w64-mingw32, distinct from MinGW’s <cpu>-pc-mingw32; * GCC supports both, and uses the -w64- part to distinguish between “plain” MinGW support and MinGW-w64 support; * the Windows cross-compiling community at large uses <cpu>-w64-mingw32. (Note that the GCC docs claim that -pc-mingw32 is used for MinGW-w64, but that’s incorrect.) Guillem has explained in previous emails why -w64-mingw32 causes issues in Debian. There are other problems with the triplet which haven’t been mentioned so far: mainly, that the same triplet is used for different compiler configurations which effectively result in different ABIs. For 32-bit targets, there’s DW2 v. SJLJ (64-bit only used SEH); for all targets, there’s POSIX v. Win32 threads; a more recent development is support for UCRT instead of MSVCRT. I see two main questions to answer: * for Debian multiarch, what triplet(s) make most sense? * ignoring multiarch, how can we provide a useful cross-compiler which supports all the target setups users are likely to need? -m options via spec files? I’ve been working on the latter mostly. I’m fairly busy just now so I won’t necessarily be all that responsive, but I’m interested in your thoughts on the subject. Regards, Stephen
Hi Stephen,
Stephen Kitt wrote:
Thanks for this breakdown. The first sounds like (partial) architecture
bringup, the second is an additional compatibility goal, and the third
could be achieved using multilib but is simpler with multiarch.
If I label these as (a), (b), and (c), then which of these goals is
important to you? What about others in mingw-w64 and related
projects?
a. provide a Windows cross-development environment useful for building
non-trivial programs and their installers
b. provide a Windows cross-compiler that integrates well with
existing externally provided libraries
c. provide a Windows cross-compiler sufficient to meet the needs of
Debian packages such as wine, mono, and so on
For bringing up a Debian arch, I would expect (a) and (c) to be
important and (b) to not be important at all. On the other hand, I
wouldn't be surprised if some other people have (b) as a goal, and if
it's easy to get for free then we shouldn't forget about it. :)
[...]
will run into the same problems.
Yes.
For architecture bringup, you left out the most important question of
all: what ABI do you want to use for the new architecture?
Given a choice of ABI and how to name it, it's possible to make
progress within Debian without waiting for upstream. We'd want to
keep upstream involved every step of the way and to benefit from their
expertise, but part of the magic of having a single project for an
entire operating system distribution is that in the worst case we
*can* go it alone.
In fact I doubt that would be necessary. Upstream has similar goals.
Picking a triplet without coordinating with upstream would be highly
dangerous unless we stick "debian" in there somewhere (yuck). I only
mention it as a way to avoid forgetting our responsibilities: if we
aren't able to find the right way to serve these users, in the end we
have no one to blame but ourselves.
Thanks,
Jonathan
Hi! Just noticed this change to the GNU config project which I wanted to add a reference here: https://git.savannah.gnu.org/cgit/config.git/commit/?id=91f6a7f616b161c25ba2001861a40e662e18c4ad Thanks, Guillem