| 1 |
"Lorenzo Milesi" <lorenzo.milesi@×××××.com> posted |
| 2 |
29c147bd0606010315oc21155bi6aed93aa2f343ef6@××××××××××.com, excerpted |
| 3 |
below, on Thu, 01 Jun 2006 12:15:38 +0200: |
| 4 |
|
| 5 |
> Last week gcc 4.1.1 got unmasked. |
| 6 |
> Someone of you already upgraded? |
| 7 |
|
| 8 |
Hehe, upgraded to 4.0.0 when it came out, then the alphas for |
| 9 |
4.0.1 as they came out (since they right away fixed some |
| 10 |
critical 4.0.0 issues), then 4.0.1-4.0.3 as they came out. Upgraded to |
| 11 |
4.1.0 when it came out, and 4.1.1 too. eselect compiler switches between |
| 12 |
the various slots as necessary, but I've been using the latest upstream |
| 13 |
full release as my default system compiler since 4.0.1, and was using the |
| 14 |
latest 4.0.1-weekly-snapshot previous to that since 4.0.0. Only when I |
| 15 |
had problems with the latest upstream release (or snapshot between 4.0.0 |
| 16 |
and 4.0.1) have I reverted to earlier versions, altho early in the 4.x |
| 17 |
series there was quite a bit of that as 4.0 was as usual rather stricter |
| 18 |
than the previous versions and therefore caused ebuild failures for a fair |
| 19 |
sized list of packages, until they were patched to be 4.x compatible. |
| 20 |
|
| 21 |
Somewhere along the line I even did the emerge --emptytree world thing, I |
| 22 |
think with 4.1.0. Anyway, all my 4.x upgrade and compatibility issues are |
| 23 |
long since behind me, months ago, and the 4.1 series has actually proven |
| 24 |
far more stable for me than any previous series since the original gcc |
| 25 |
hammer/amd64/x86_64 support, back with 3.2 IIRC. =8^) |
| 26 |
|
| 27 |
> I did it this week, and actually I'm having troubles with Boinc and |
| 28 |
> Gaim. Gaim has stopped working just this morning, as I recompiled glibc |
| 29 |
> with gcc4. :( |
| 30 |
> |
| 31 |
> Anyone had the same experience? |
| 32 |
|
| 33 |
Not here, at least not since the 4.0 series was the latest upstream |
| 34 |
release timeframe. |
| 35 |
|
| 36 |
BTW, the 4.1 series is IMO the biggest jump in gcc efficiency for amd64 |
| 37 |
since the -march=k8 support got added in 3.3. As the first rewrite that |
| 38 |
had amd64 factored in from the beginning, not bolted onto the side, the |
| 39 |
4.x series in general had the potential, but the 4.0 series was mainly |
| 40 |
targeted at not having too many regressions for the basic rewrite, so was |
| 41 |
actually lower efficiency in some cases. 4.1 finally sees that potential |
| 42 |
blossoming, and things are /dramatically/ faster with it. At least, that |
| 43 |
has been my feeling/experience. |
| 44 |
|
| 45 |
That's in addition to being the most stable gcc series yet, in terms of |
| 46 |
amd64 support, from my experience. (YMMV of course, particularly if you |
| 47 |
have widely differing USE flags than I do and/or a widely differing world |
| 48 |
list. |
| 49 |
|
| 50 |
While there will certainly be upgrade pains, once they are over, I hope |
| 51 |
everyone has as smooth a sail as I've had! |
| 52 |
|
| 53 |
|
| 54 |
|
| 55 |
-- |
| 56 |
Duncan - List replies preferred. No HTML msgs. |
| 57 |
"Every nonfree program has a lord, a master -- |
| 58 |
and if you use the program, he is your master." Richard Stallman |
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-amd64@g.o mailing list |
Archives