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 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_at_ 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. 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. 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? 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_at_ 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? > >-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.) >> 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? 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. ;) >> 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. 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... -- thx, Paul Seniura.Received on Thu Jul 29 2004 - 14:50:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:03 UTC