On Wed, 4 Dec 2013 09:06:17 +0100, Guillem Jover <[email protected]> wrote: > On Wed, 2013-12-04 at 00:00:21 +0000, Dmitrijs Ledkovs wrote: > > I've carefully reviewed the whole thread and re-reviewed the proposed > > patch: > > > > * vendor tag is _not_ used to encode API/ABI, GNU_SYSTEM is > > "w64-mingw32" - GOOD (agreed by everyone in the thread) > > 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).
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
signature.asc
Description: PGP signature
