Date: Thu, 29 Jul 2004 19:43:59 +0000 From: Alexander Kabaev <kan@freebsd.org> To: Paul Seniura <pdseniura@techie.com> Cc: freebsd-current@freebsd.org Subject: Re: about the gcc 3.4.x problems Message-ID: <20040729194359.GA69301@freefall.freebsd.org> In-Reply-To: <20040729164738.523C85CA2@techpc04.okladot.state.ok.us> References: <20040729144205.6ABEF5CA2@techpc04.okladot.state.ok.us> <20040729164738.523C85CA2@techpc04.okladot.state.ok.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 29, 2004 at 11:47:38AM -0500, Paul Seniura wrote: > > Scott Long wrote: > >On Thu, 29 Jul 2004, Paul Seniura wrote: > >> > >> In my neck of the woods 'round here, problems with GCC 3.4.x are > >> not new. For history's sake if nothing else, please take a look > >> at a msg thread I started on this list back in April 2004: > >> <http://docs.FreeBSD.org/cgi/mid.cgi?20040402210539.70E945C3B>; > >> > >> We were _never_ able to compile kernels with 3.4.x -- there were > >> too many options & other things that are no longer supported. > > > >Most of the problems that you site here and elsewhere have already been > >resolved. Alexander has spent an _INCREDIBLE_ amount of time on gcc 3.4. > > I'm sure he has. Not putting anyone down for the work being done. > Being able to DISCUSS things with these people is another matter. > And I'm saying here & now that I feel like I was left out in the cold, > starting in April 2004. What you posted then and what you tried to do was a demonstrable proof of you not knowing what differences between GGC versions in ports and base system are. That didn't change, and hardly invites DISCUSSION. With all due respect, I am not obliged to respond to messages which have higher than usual chance to result in wasted time. > >What he imported is not the same as what you might have installed from the > >ports tree back in April. > > Of course it isn't the same. > I _know_ it isn't the same. > I am on record here saying I'm having to follow -Current via CTM. > I suppose I must constantly reiterate that little fact. ;) > I wouldn't broadcast on the -current@ list if I wasn't running -Current. ;) > In fact I had to wait two days because the system gcc commits were not > completed by the 16-hour deadlines when the CTM deltas are created & mailed out. > (Again I'm on record explaining the Political Firewall here won't let > us do CVS/CVSup.) > The patch for providing the -fformat-extensions option *just* showed up > in the CTM delta that just got mailed out a few hours ago. > That's why I am _only just today_ able to start genning a new kernel & world > with _all_ of y'all's fixes _finally_ in place. > I'm trying to explain that the -fformat-extensions problem was known > even back in April 2004. Sorry, I will shoot for 'fastest committer under Sun' title next time. If your update cycle is so slow, it might be a good idea to wait little longer before jumping to conclusions. Let alone airing them out on public mailing lists. > This puny pentium2 finally finished compiling the lang/gcc34 port last night, too. > It is a snapshot that 'gcc34 -v' shows: > >>>> > Reading specs from /usr/local/lib/gcc/i386-portbld-freebsd5.2/3.4.2/specs > Configured with: ./..//gcc-3.4-20040723/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=34 --with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd5.2/3.4.2/include/c++/ --enable-shared --prefix=/usr/local i386-portbld-freebsd5.2 > Thread model: posix > gcc version 3.4.2 20040723 (prerelease) [FreeBSD] > <<<< > I'm also tracking gcc33: > >>>> > Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.3.5/specs > Configured with: ./..//gcc-3.3-20040630/configure --disable-nls --with-system-zlib --program-suffix=33 --with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.3.5/include/c++/ --enable-shared --prefix=/usr/local i386-portbld-freebsd5.2 > Thread model: posix > gcc version 3.3.5 20040630 (prerelease) [FreeBSD] > <<<< > > >He also spent quite a bit of effort to resolve > >coding problems that trip up gcc 3.4. So maybe you should actually update > >your system to the post gcc-3.4 import and actually see if it works rather > >than making assumptions that it doesn't. > > Why do you always assume I DO NOT follow -Current??? > It also seems like you don't use maillist archives to read-up > on the history of a discussion. > See above. > > > >There are a few problems that > >are still being resolved, but that is quite normal after a major compiler > >update. > > Somewhere along the way I'm sure I mentioned having to remove the > -fformat-extensions option in the makefiles during my tests with the > newer GCCs. Since gcc34 is a snapshot (even today as I just quoted), > I didn't file a PR. IIRC others stumbled onto it, too, and actually > mentioned it here. At any rate, _anyone_ would have stumbled on it > if they'd used the lang/gcc34 port. There was a reason why gcc34 port was kept free of local FreeBSD hacks. The reliance of FreeBSD on a number of private extensions was a well known fact to anyone who tried to understand the difference between GCC tarballs as distibuted by FSF and base system version of the compiler as shipped for FreeBSD. The number of such hach has gone down significantly in recent years, but nonetheless they still do exist. I do not really understand the need to act so shocked when you finally became aware of this in April 2004. > Go into the maillist archives and find out what else I've said in > regards to GCC 3.3x and 3.4x being officially released but we do not > have them, instead we have snapshots. We have not recently had > lang/gcc* ports that are in final form. I definitely asked the > question: How might we get and test the 'final' releases, please? I assume you know, that GCCs we use are coming from stable branches in FSF CVS repository? Dreaded snapshots we are importing are generally more bug free than the release they come after. > No answers yet. > And so I ask it again now. > >> I was attempting to notify y'all about various problems with the > >> newer GCCs WAY IN ADVANCE to hopefully get someone here to help me > >> fix these problems. IMO there is no excuse for these bugs at the > >> current time. It just seems to me everyone ignored my original > >> posts (and other people's) about these problems. If someone had > >> done "homework" right here on the -current@ maillist, that person > >> would've known more testing was in order before committing this > >> 3.4.x change. I never got much useful feedback from that > >> April 2004 thread. > >> > >> The problems with -Os and 3.4.x were known to the GCC team > >> themselves, too. Pointers to this bit of info should be in the > >> mentioned April 2004 thread. I also mentioned therein about how > >> I could not feel right in logging a bug at the GCC website due to > >> the FreeBSD patches being applied on top of their code. I do not > >> know where the culprit is -- in GCC's src or in FreeBSD's patches? It should not be too hard to guess why port does not carry local patches now. I would love to see more PRs from FreeBSD people coming to GCC Bugzilla database and fully expect to see couple of yours now, as ports vs. system compiler mystery is not a mystery anymore. There is always an option to build a compiler directly from FSF release source is one were so inclined. Contraty to popular belief, this daring procedure works most of the time. You keep waving your April posts as if they are supposed to contain something actually useful. Problems with -Os and 3.4.x that 'were known to the GCC team' have absolutelty nothing to do with -Os build breakages people have been reporting when using -O2 or higher optimization levels. Incidentally, I just committed some fixes to address them, so I am not guessing like you, I know for sure. And of course the problems were in FreeBSD code, not in compiler itself. Perfectly good example of GCC 3.4.2 not being ready for prime time, I guess :) > > > >-Os has never been a supported option for compiling the system on FreeBSD. > >There is an effort to make -O2 work, but that is also not officially > >supported yet. Many of the problems are due to FreeBSD code, of course, > >but this is a long standing issue and has little bearing on the success of > >the gcc 3.4 import. > > Okay I am also on record here about the -Os being the DEFAULT SETTING > on Apple's XCode "deployment" environment. It _needs_ to be > supported. (I'm wondering just how much history y'all have > read in regards to what I've specifically mentioned over the > past few months even when I stick a URL here to go read that > history. I am constantly having to repeat these items.) And FreeBSD is related to Apple's XCODE requirements how exactly? Constanly repeating content-free URL does not provide answers, really. > > >> Now... I have another bit of New Info to add to this discussion. > >> > >> Apple is planning on using GCC 3.5 for the next big overhaul in > >> OSX called 'Tiger'. This has been massively publicly reported in > >> the usual circles, so I'm not "spilling beans" about anything > >> covered in the NDA. BTW I'm not sure if the Tiger pre-release at > >> the WWDC includes GCC 3.5 in its version of XCode (TPTB here > >> won't pay for such trips, nor will they pay for a higher ADC > >> account, so I'm not privvy to the new preview software), but at > >> any rate GCC 3.5 _is_ slated to be in XCode 2.0 when Tiger goes > >> final. > >> > >> Currently we are still using GCC 3.3 in Panther XCode 1.2. > >> > >> Here, then, is a point I need to make: > >> > >> Why is Apple seemingly skipping GCC 3.4.x altogether? > >> > > > >So is there a conspiracy against gcc 3.4 that we don't know about? Do you > >have information that could help us here? Or maybe Apple is just being > >prudent and targeting XCode and GCC releases to somewhat coincide. That > >seems to satisfy occums razor a whole lot easier. > > I said "seemingly". > It makes sense to me.[tm] > It is something to think about. > > Would you provide me the money & time-off so I can go to the WWDC and > maybe find out their official reasons? You spread the rumors, it is your responsibility to prove them. This makes sense to me too. Until then there is nothing of substance to substantiate your gut feelings. > > These state govmt tightwads sure won't. > Even when I've submitted a cost analysis. > Your tax dollars hard at work. > (don't get me started -- I'm really p'v'd at TPTB here) > > At any rate, GCC 3.5 has been available for some time. > I wish I had Alexander's smarts to do a port of it. > The way I test things is to use the official srcs without layering > a bunch of custom patches on top of it. > If your srcs don't compile right, must be something wrong with > your srcs, AFAIK me being the gcc-portmeister if I were to be. > ;) I wish you knew where GCC folks keep their release plans. Hint: they do not hide them from public so they CAN be read and facts can be checked before being posted. > > >> To me this really looks like 3.4.x was having problems for them, > >> too. 3.4.x plain ain't ready for prime time PERIOD. > > > >Are there documented facts to back this up? Again, your tests from April > >aren't terribly relevant anymore since everything has changed quite a bit > >from then. > > Have you searched the mail archives here to find out what's > been said during the past few months? Again I'm sure some > of us including myself have mentioned the -fformat-extensions > problem at several points. Having most modules linked with > libstdc(++) in the i386-portbld-freebsd5.2 subdir is not too > kosher, too. I mentioned all kinds of things like that. Why on Earth do you believe that building world and kernel using GCC from ports is supported? > When I get no useful feedback and say I must drop the > testing, "that's a clue" to y'all meaning I give up and I > need help. Go read the archives if you need the proof. > > > >> I never got much useful feedback from my April 2004 thread. > >> So I had to drop our tests of GCC 3.4.x. > >> > >> I'm *extremely disappointed* of many things going on in the past > >> few months (yanking MIDI support was #1 before this). I'm trying > >> to be involved in as much of -current as I can. And many of my > >> own-initiated discussions seem to go no-where real fast. > >> > >> And then *BOOM* we are forced to use GCC 3.4.x with known bugs & all. > >> This surpasses yanking MIDI in my #1 Gripe List. > > > >FreeBSD is not like other well-known open source operating systems. The > >compiler is integrated into the OS, not an optional component that can be > >switched at will. This has good sides and bad sides. However, the gcc > >import wasn't done on a whim. It wasn't like Alexander got off a weekend > >bender and decided to do it because he was bored. It was heavily > >discussed and coorinated in just about every way that it could be. For > >you to suggest otherwise is incredibly rude. > > I follow these maillists like a glove on my hand. > I have said and will say again I didn't receive any useful feedback as to > how to proceed with the tests on lang/gcc34 -- starting in April 2004. > Again I'm on record saying many other maillist sites are blocked by our > firewall (and don't say "it is broken") -- I only have access to _these_ > lists _here_, and I honestly have not seen those highly detailed discussions > going on about GCC here. > > But now we are crying over spilled milk. > > What I should get started on RSN is GCC 3.5. > Where & how can I help with it? > > >As for Midi, I'm sure that the maintainer would be interested in whatever > >constructive conversation you have, and might even be interested in code > >that you might have developed to help resolve the situation. > > > >Scott > > Again my discussions about this are in the maillist archives, > public for all to see. Including yourself. ;) > > And yes I'm still waiting for some useful feedback... I think you got one now. And look, it even matches the tone you started with. -- Alexander Kabaev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040729194359.GA69301>