Re: Bug#648306: The mingw* mess in Debian
On Fri, 11 Nov 2011 07:36:28 +1030, Ron <email@example.com> wrote:
> I was hoping you'd actually been cc'd on this :)
I was a few days behind debian-devel so I found out aboud the discussion
thanks to Fabian's bug report, which you will have received too ;-).
> 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
details.) There may be other non-political differences I'm not aware of.
> 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 :) continuity for
> 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
> > 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.
> 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
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...