Description of problem:
gcc 4.4 was released on 21st April, a little later than feature fedora 11 freeze; and the mingw people has also released a mingw patch set, with some mingw specific changes a few weeks ago... wouldn't it be nice to upgrade and synchronization with upstream (gcc or mingw)?
I also noted that the fedora shipped compiler uses sjlj exception, apparently dwarf2 is the supported model...
see the fedora-mingw list for exception handling discussion.
Created attachment 353901 [details]
diff of my spec vs the fefora -0.7 spec file
As a proof of concept, I have unpacked the fedora mingw32-gcc-4.4.0-0.7.fc11.src.rpm and modified it to use the upstream release tar ball, plus all 13 of mingw patches.
5 of the fedora patches didn't apply (patch 0,24,25,26,27):
I think both patch 24 and 25 was incorporated upstream and can be dropped, and 26,27 are partially incorporated upstream and need some work; not sure about the purpose of patch 0.
Out of the 13 mingw patches from gcc-4.4.0-mingw32-src-2.tar.gz (from mingw), two has slight problem: "gcc-4.4.0-20090418-dllimport-libstdc++.patch" has some typo itself which is reported upstream (see my recent post to mingw-devel mailing list), "gcc-4.4.0-20090418-libjava_s.patch" duplicates one chunk which is also in the fedora patch. Both are trivial problems and quite easy to fix for anybody who knows a bit of C.
I also noticed that the new default is to build the language-specific libfortran.dll, etc, but there is no sjlj dll (no exception?), so I added the disable-shared (to stop the generation of libfortran, libobjc, etc) and --with-dwarf2 .
I hope somebody examine the 5 failed fedora patches (maybe take a look at the native compiler src rpm? it seems to be newer than mingw32-gcc) and also merges the mingw patches in properly.
(In reply to comment #1)
> see the fedora-mingw list for exception handling discussion.
I only found a thread in Nov 2008. The situation has likely changed since (particularly with the release of gcc 4.4 from gnu.gcc , and also a mingw gcc 4.4 release plus patch set). Maybe somebody in fedora should re-visit this issue.
Hmm, it looks like the fedora patch set is simply the same set from the native compiler around the same time (except dropping fastjar-0.97*). and I see some mention of strange relationship between fedora and gcc... but in any case, I reckon some of the 13 upstream mingw patches could be incoporated?
Created attachment 354033 [details]
tarball of mods for latest gcc from koji
This is a tarball of a modified mingw32-gcc specs file to use the latest native gcc from koji (4.4.0-13), and all the upstream mingw patches.
3 of the 13 upstream patches need some adaptation (so attached). Two of the 3, gcc-4.4.0-20090418-libjava_s.patch gcc-4.4.0-20090418-ada-hang.patch look like they are partly in fedora native gcc anyway; the 3rd one is slightly broken and reported upstream. The result seems to have build libgfortran.dll, etc extra compared to old.
On a different matter, the upstream mingw gcc release notes have these paragraphs:
- Zero cost exceptions: New exception model Dwarf only has performance
penalty when being thrown. The old model, SJLJ, is no longer
- Dynamic linking with libgcc_s_dw2-1.dll
Dynamic linking with libgcc_s_dw2-1.dll is necessary to throw
exceptions between different modules, such as between two DLLs or a
DLL and an EXE. Consequently, it is the default for all languages
other than C. To disable this dynamic linking, use -static-libgcc.
To enable this dynamic linking in C, use -shared-libgcc.
I haven't been able to get a dw2-1.dll at all, and some experiment (disable-shared) results in broken dependences - a few packages mingw32-gettext/boost/pthread have explicit dependency on the sjlj-1.dll.
it's not that simple. since we build all current dlls with sjlj we've to rebuild all mingw packages and none of the previous dlls can be linked with current ones:-(
(In reply to comment #6)
> it's not that simple. since we build all current dlls with sjlj we've to
> rebuild all mingw packages and none of the previous dlls can be linked with
> current ones:-(
Bring the package up to date source code-wise and incoporating the 13 upstream mingw patches, and switching the exception model are two different issues - the former is easy (and I already did it with the tarball I posted). The latter I know is a bit tricky.
OTOH, I have 39 of mingw32-* packages on my system and only 4 have a sjlj-1.dll dependence (from "rpm -q --whatrequires 'mingw32(libgcc_s_sjlj-1.dll)'") - mostly libraries written in c++ or one with a non-c binding. A majority of mingw32 packages currently available from fedora 11 are not affected if a switch is made - you just need to rebuild *some* packages, and a minority, I think.
I think a switch should be made *eventually*, especially now that the mingw project itself has switched to dw2. Maybe for the f12 time frame? - should I file that separately?
I have now updated mingw32-gcc package in rawhide to 4.4.1 snapshot to match the version of the native gcc package. The update was also discussed on fedora-mingw mailing list .
I'm closing this bug as fixed. Please open another bug for changing the exception model. It's a change that should be done early in Fedora 13 cycle. For Fedora 12, however, the exception model most likely remains sjlj.
mingw upstreams have a bundle of some 12-13 patches:
consider incorporating them?
(In reply to comment #9)
> mingw upstreams have a bundle of some 12-13 patches:
> consider incorporating them?
Yes they were considered. See http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-August/001997.html for the discussion. After this mailing list discussion, we continued on IRC (FreeNode, #fedora-mingw). It wasn't clear to us whether it was safe to apply these patches as none of us is familiar enough with the GCC internals. Next to this we're using a different exception model right now (which is planned to be changed for Fedora 13). We all agreed that if the patches are really necessary then they should be upstreamed by the MinGW folks anyway. So in the end we refrained from applying the MinGW patches (at least for now).
IMHO fedora-mingw's GCC should match the upstream MinGW code (including patches) and exception handling, to be binary compatible with things like the kdewin binary packages. (Right now, the old binaries built with MinGW GCC 3.4 are probably compatible, but those are going away at kdewin and probably most other upstreams.)
I'm also familiar to some extent with the GCC internals, due to my work in the TIGCC project. I could have a look at those MinGW patches. But I don't see them being "unsafe" at all.
Kevin, that would be great. Thanks.
I did a quick review of upstream mingw patches and posted the results  in the fedora-mingw list. Could we continue the discussion in there? Mr. Leung might also want to subscribe to the fedora-mingw list.
I think we should switch the exception model to dwarf2 early in F-13 cycle, and this is the time when some of the mingw patches might come handy. If you take a look at , you'll see that right now most of the patches aren't very useful because they are either related to languages we don't build (ada, gcj) or contain fixes to dwarf exceptions.
I thought it was decided to ship F13 with a MinGW toolchain binary-compatible with upstream MinGW? So why are we still shipping a GCC with SJLJ expections and without MinGW patches in F13 and even F14 Rawhide? :-(