Bug#606825: dpkg: Please add mingw to ostable and triplettable.
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606825: dpkg: Please add mingw to ostable and triplettable.
On 13 December 2010 23:21, Jonathan Nieder jrnie...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606825: dpkg: Please add mingw to ostable and triplettable.
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 jrnie...@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-wi...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606825: dpkg: Please add mingw to ostable and triplettable.
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. pgpxZxcgoI3EI.pgp Description: PGP signature From 8315953b2bc7d400ed320b57e8eb5caed90e6da8 Mon Sep 17 00:00:00 2001 From: Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Date: Sun, 12 Dec 2010 00:15:22 + 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
Bug#606825: dpkg: Please add mingw to ostable and triplettable.
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
