Re: Bug#648306: The mingw* mess in Debian
Hi Ron,
On Fri, 11 Nov 2011 07:36:28 +1030, Ron <ron@debian.org> 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
https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for
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
-w64-mingw32 triplets.
> > 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
guidelines.
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...
Regards,
Stephen
Reply to: