From: Dmitrijs L. <dmi...@ub...> - 2010-12-15 16:09:03
|
On 15 December 2010 13:36, NightStrike <nig...@gm...> wrote: > On 12/14/10, Dmitrijs Ledkovs <dmi...@ub...> 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. 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. >>> >> >> 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. |