This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.  <>  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 yourself"

Otherwise, can we PLEASE have a moratorium on those absolutely UNHELPFUL "fixed in 4.x" "answers" to bug reports?


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]