This is the mail archive of the
mailing list for the Cygwin project.
Re: g++ 4.1?
[okay. so this is a rant and went off a little bit from the actual
thread topic. But I've wasted a too much of my life these past few
months on gcc/g++ issues, so now I'm gonna vent...]
Brian Dessent wrote:
WJFFM. <http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01102.html> I
have never experienced either of the issues you mentioned. The
"successful reports" thing is completely bogus. Just look in the
testresults archive, you'll see plenty of people build and test gcc 4
under Cygwin regularly.
Sure. and all of these people have tested all known issues such as
exception propagation from DLLs in C++ -- which isn't covered by the
test suite? Do they even KNOW about some of the issues like DWARF2/sjlj
interactions with native windows? and NOBODY, but NOBODY, has succeeded
in getting a real, working, exception-supporting build of libgcj in 4.1
or later (over 900 libjava testsuite failures, Brian? That's your idea
of "WJFFM"? You've gotta be kidding.)
I'm sorry, but this just REALLY pisses me the hell off. On both the
cygwin and mingw lists, the answer to bug-report-of-the-day with gcc is
always "fixed in 4.0" or "fixed in 4.1" or "fixed in cvs" -- as if any
Joe Schmoe is just supposed to build his own gcc on our fscked-up
platform -- AND this Joe Schmoe is gonna be able to build a working 4.x
gcc when **not even the official maintainers on either cygwin or mingw
are willing to publish a 4.x gcc even as a 'testing' or 'candidate'
version!**. And Joe Schmoe's unguided attempt will "just work"?
Sorry. That Is Not True.
I'm not a Schmoe. I've built gcc and binutils on multiple platforms,
including cygwin, mingw, linux, solaris, and (god forbid) irix -- and
it's ALWAYS touchy (and heaven help you if you're trying to build
multilib. Just Say No.). Every platform has wierdnesses in its
binutils/gcc build process. There's always some out-of-tree patch that
should be applied to fix something that was missed in the release
process. Ours has more than most.
Let's not dance around the issue: gcc is a fundamental, core component
of both cygwin and mingw platforms -- and it has been essentially
unmaintained for a long time, tho that may be changing. And building
gcc/g++/etc *correctly* is NOT a simple task -- just look at how long
it's taken an ambitious, industrious, knowledgeable and bright guy like
Dave Korn to 'get up to speed' as he is taking over as cygwin-gcc
maintainer. You can usually say "build the latest wget" with some
expectation that with just a little effort, the addressee will be able
to do it if they care to. Not so with gcc -- It. Is. Hard. (and
requires a lot of "tribal knowledge" -- not actually written down in any
one place -- to get right)
AND there's at least one fundamental issue that IS NOT SOLVED in 4.0 and
later: exceptions propagation from DLLs -- I don't care how many
"success reports" appear in that testarchive. (And 29 testsuite
failures in libstdc++ is not wonderful, either!) Also, the std::string
issue that cygwin-g++ has in 3.4.x AFAIK has not been fixed in 4.x yet,
either, so that's another out-of-tree patch needed.
I tried looking at all the patches in the official cygwin gcc-3.4.5
package(s) and checking the 4.1 code to see if they ever made it in --
and that is a huge task, as the 4.1 code has seen a LOT of changes in
two years. I didn't get far...but there were some. Then there's the
whole side issue of shared runtime libs -- which, while desirable in
itself, is also the "approved" way forward to fix the excp prop issue in
C++ as the originator of the patch in 3.4.5 has no intention of ever
forward-porting that patch to 4.x.
If it truly, truly, WJFFYou -- but given the testsuite results you
posted, I dispute that assessment -- then PLEASE post in reply to this
message your EXACT build procedure, configury settings, out-of-tree
patches, strange hacks you had to do in /usr/include, environment
settings during the build, ... you know, all those touchy little things
that can break a gcc bootstrap if they are not set JUST RIGHT.
Then, next time, when somebody reports a bug -- we can all point to your
post and say "works in 4.x -- follow Brian's procedure and build it
Otherwise, can we PLEASE have a moratorium on those absolutely UNHELPFUL
"fixed in 4.x" "answers" to bug reports?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html