delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/06/23/17:24:42

X-Spam-Check-By: sourceware.org
Message-ID: <449C5B93.1000805@cwilson.fastmail.fm>
Date: Fri, 23 Jun 2006 17:22:27 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: g++ 4.1?
References: <loom DOT 20060620T220001-703 AT post DOT gmane DOT org> <44987580 DOT 32006EA AT dessent DOT net> <afe5197f0606230600p1bd4c91av7e88eaf4a55a0aca AT mail DOT gmail DOT com> <449BE972 DOT B1D2CA47 AT dessent DOT net>
In-Reply-To: <449BE972.B1D2CA47@dessent.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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

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

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019