Hi Ron, On Fri, 11 Nov 2011 07:36:28 +1030, Ron <r...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
