On Mon, 14 Nov 2011 03:03:16 +1030, Ron <ron@debian.org> wrote: > On Sun, Nov 13, 2011 at 01:17:43AM +0100, Stephen Kitt wrote: > > 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.) > > 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 ... OK, thanks for the info - I hadn't actually checked the Debian packages. I do know that some MinGW-build packages "in the wild" use libgcc_s_dw2-1.dll rather than libgcc_s_sjlj-1.dll as provided by gcc-mingw-w64; but that's neither here nor there as far as the migration we're discussing is concerned! > 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 > those people :( I knew the history of the mingw32msvc name, but not that the change was gratuitous... Looking around the Internet it seems i586-mingw32msvc is still in use (if only because of "old" instructions using Debian's own mingw32 packages), and the new mingw-w64 triplets are referenced as well, but there's not much sign of the new mingw triplets. [snip] > > 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. > > 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. There's still one issue I know of; see #635439. None of the packages in Debian caused much trouble migrating to mingw-w64; if I remember correctly the main issues were related to switching to gcc 4.6 rather than mingw-w64 itself. In software not packaged for Debian I've come across problems where the software being built defined stuff from Windows which wasn't directly supported in mingw32 but is now in mingw-w64; that's usually easily worked around. > > 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 > this out. :) You're welcome! > 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. I tried a build using i586-mingw32msvc, and it worked; things also work if I just add i586-mingw32msvc- links to the i686-w64-mingw- binaries. Do you think it would be OK to keep the mingw-w64 packages as is (to make upstream support easier - they're the only "alive" upstream), and have mingw32 replacement packages with symlinks as above? Regards, Stephen
Attachment:
signature.asc
Description: PGP signature