> GCC 4.2.0 has been released.
> What would mingw users like for a binary release package?
> (1) Based on pristine (well, just a few makefile.in tweaks to get around
> CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs.
I'm going to go out on a limb and say "1". It has been three entire
/long/ development cycles -- to 4.0, to 4.1, and now to 4.2 -- since
mingw had a "current" version of gcc; I don't think any of us want to
see that kind of lag-behind happen again.
But one way to guarantee that it WILL happen is to have "our" version be
wildly divergent from the official releases: because then we keep
bugfixing out on our limb, and then we get:
.."it's just too hard/too big to submit these changes"
.."ah, 4.2.x isn't maintained anymore, they're working on 4.5.x"
.."I didn't write /that/ part so I can't submit it"
.."Well, we can't release 4.3.x because it doesn't have all these custom
Hence: we drift away, and are stuck with 4.2.x for years and people
start peppering the list with "when are you going to release 4.5.0?"
So we get to re-experience the current pain all over again for gcc-4.7.0.
No, option (1) is better. And yes, the tweaks should be submitted for
And THEN, we can start backporting select features from 4.3.x -- but
only those that would be candidates for submission to the official 4.2.x
branch. And then we /should/ submit those also to 4.2.[1+]
In Chuck's world, the *only* exception to the preceeding rules would be
the shared libgcc stuff: because that's the recommended (only?) road to
getting exceptions-across-dll-boundaries working for both C++ and java
If people want spiffy new features (along with spiffy new bugfixes AND
spiffy new /bugs/) then maybe an EXPR-gcc-4.3.0 release would be a
better testbed for /that/, with all the dw2 and shared libgcc bells ad
whistles. Besides, gcc trunk will have modern, mingw/cygwin-friendly
libtool support before long <g>.
> (2) As above but backporting select features from 4.3.0, fixing some
> aforementioned known bugs.
> (3) As (2) but enabling DW2 unwind.
> (4) As (2) but building libstdc++ and libgcc as dll's.
> (5) (3) | (4).
Just a side note: even though DW2 unwind is faster, better, and more
widely used (and thus more widely tested) than sjlj, IMO mingw should
still supply a sjlj compiler, at least as an alternate download -- until
the foreign frame problem is solved:
"DW2 EH is supported for Windows, but someone needs to implement the
part that makes it possible for GUI callbacks to throw exceptions that
can be caught in the main event loop, i.e. make exception-propagation
work through "foreign" call frames in the stack.
If I understand correctly, ^^^ is predicated on having shared libgcc --
hence the exception-to-the-rule in Chuck's world.
For my own use, I'd *love* (5) -- but I'm deathly afraid that we'd just
be ASKING for trouble down the road if, once again, the official mingw
compiler version "x.y.z" deviates so significantly from the official GNU
compiler version "x.y.z".
I can deal with a slightly less capable 4.2.x on mingw -- and simply
wait another six months or so for 4.3.0, in which all these spiffy new
things will be integrated into the official GNU release (we all hope --
since we'll all be working feverishly on gcc trunk rather than haring
off on our own kinda-looks-like-gcc-4.2.x-but-man-it-is-WAY-different).
And, for mission critical stuff, 3.4.5 isn't going anywhere.