On 15 December 2010 13:36, NightStrike <nightstr...@gmail.com> wrote:
> On 12/14/10, Dmitrijs Ledkovs <dmitrij.led...@ubuntu.com> 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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
