On Sun, Nov 13, 2011 at 01:17:43AM +0100, Stephen Kitt wrote:
> > On Thu, Nov 10, 2011 at 08:16:01PM +0100, Stephen Kitt wrote:
> > > As far as the naming is concerned, see #622276 for details. I've thought
> > > about splitting the packages up, with separate 32- and 64-bit targets, but
> > > I'm not sure whether replacing and providing the mingw32 packages would be
> > > correct, since mingw-w64 isn't a drop-in replacement (the triplets are
> > > different). If that's not a problem then why not!
> > Ewww, why on earth did they change the triplet for the 32bit builds?
> > It's not actually a different architecture, or even a substantially
> > different toolchain.
> There is one major difference I know of: i686-pc-mingw32 (the official MinGW
> triplet) builds with Dwarf2 exception handling, whereas the -w64-mingw32 (the
> official MinGW-w64 triplets) build with SJLJ exception handling because
> Dwarf2 doesn't work on Win64 and isn't compatible with DLLs built with
> anything other than gcc. (See
> https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for
Actually, that's not quite true. At least for the case we care about here
anyway ... The dwarf2 handling never really was quite finished, and never
really did work quite right. That might have changed now, but the mingw32
toolchain we are migrating from here is also an SJLJ build ...
The 'official MinGW' triplet you quote above was also a gratuitous new
change made 'fairly recently' by the new folks there. From what I saw when
they did that it was mostly an arbitrary choice made by new people who had
no idea that we needed the msvc qualifier because there was *also* a crtdll
build variant way back in ancient times, which existed before the msvc builds
were actually reliable, and which was still in use when this toolchain was
first uploaded to Debian.
They then went on to foam about distros using i586-mingw32msvc, which had
been in use for more than 10 years before those people ever came along ...
Which is about the point that I stopped hoping for sane new releases from
> > If you've actually got this all building from the mainline sources now,
> > I'd have been all for folding this into the original mingw packages and
> > having some sort of sensible (if somewhat interrupted
> > people down that track ...
> > but if it's gratuitously incompatible, then I don't really know what to
> > do or think about that ... modulo pity for the people getting burned.
> I could be wrong about this, but I don't believe it's gratuitously
> incompatible. The thing is though that end-users are now used to the
> -w64-mingw32 triplets.
Well, that's why it's a horrid mess
The dead mingw fork changed it for
no good reason, and so did the w64 fork ...
Saying "end users are now used to the new one", isn't much of a consolation
to the people who've been using this since the 1990's without having that
sort of thing inflicted on them for no actual gain. And I'll put a beer on
there being far more of those than there are people already on the -w64 train.
It's kind of like saying "end users are now used to GNOME 3" ...
And sadly I think it's probably going to end about as well
> > > The names for the 32-bit packages would probably be quite weird though
> > > since the upstream name is mingw-w64 (and I'd rather keep that in the
> > > package names...).
> > I'm not sure I really follow this, what am I missing here? What exactly
> > are you taking from 'upstream' in this case? My understanding was that
> > the toolchain was mainline gcc/binutils now, and all that the w64 folk
> > were providing was the runtime library? Is that wrong?
> That's correct, so the only really upstream package is mingw-w64 which
> provides the headers and libraries required to target Windows (it's not even
> a runtime library since there is no non-gcc runtime library). The MinGW-w64
> developers do submit patches against binutils and gcc now and again, so in a
> sense they're still providing the toolchain, they're just upstreaming
> everything instead of shipping patches.
Right, I didn't mean to say they weren't also contributing to the toolchain,
just that we aren't taking patches directly from them for this. It's the
same mainline gcc that everyone else has -- and which doesn't really have any
-w64 connotations of its own as such. So it might be better to avoid making
that association ourselves, to avoid the need for yet another rename if this
later goes and forks again.
> > mingw.org has been basically dead for quite some time now, the 'developer'
> > list has been closed to the public and the only apparent work going on
> > was for native windows installers. They were even claiming that building
> > it for platforms other than windows was officially completely unsupported.
> > All the old-blood developers appear to have moved on to other things,
> > presumably because the 'hard parts' have all been mainlined now.
> > So sourcing the runtime from somewhere else now seems like a useful
> > proposition. But changing more than was really needed to do that does
> > make describing this as a "mess" look like a generous understatement ...
> > Is it really that bad, and if so is it really too late to back away
> > slowly and make this less disruptive to established users? It would
> > be nice to actually have an orderly 'upgrade' path through this rather
> > than an "everything is different now" paradigm shift. It is just a
> > toolchain after all. For a rather old and settled architecture.
> I thought it better to follow the MinGW-w64 project's recommendations,
> including using their triplets. Because people still encounter bugs fairly
> regularly (see the bug trackers at
> https://sourceforge.net/tracker/?group_id=202880 and the mailing list
> archives), I believe we're better off if we can easily get support from
> upstream, and they're more inclined to help us out if we follow their
Does this actually successfully build everything that the old mingw toolchain
did now? There were some reports of miscompiles with the -w64 packages that
Robert first made, but I don't offhand recall which projects that was with.
That was one of the main reasons we didn't immediately kill the old toolchain.
> I'll try a build with the old triplets to see how that goes, and to figure
> out what kind of upgrade path we can provide...
Cool. Despite my grumbling about how people who paid no attention to the
history are busy reinventing pain that we were supposed to be long past,
I am actually really grateful for all the work you've put in to sorting
If things are going to break, it would be really nice to get *everyone*
with a stake in this to break it the same way and then promise not to
break it again. It's one thing for random libraries to fork with no
attachment to the established users and fiddle with things incompatibly
just to 'make their mark' on it. But that's not really something we
should be doing with toolchains for old architectures.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com