| 1 |
Mansour Al Akeel posted on Tue, 13 Oct 2009 10:25:15 -0300 as excerpted: |
| 2 |
|
| 3 |
> I lost the output from the previos build, and unable to regenerate the |
| 4 |
> issue after fooliwnf libxcb update guilde. But now I am stuck with |
| 5 |
> another error, when bulllding gcc. |
| 6 |
> |
| 7 |
> |
| 8 |
> /var/tmp/portage/sys-devel/gcc-4.1.2/ |
| 9 |
|
| 10 |
gcc-4.1.2 ? gcc 4.1 is a bit outdated. You /may/ be able to simply |
| 11 |
unmerge it. What versions of gcc do you have installed, anyway? It's |
| 12 |
likely you have a 4.3 version, as gcc-4.3.2-r3 is the latest keyworded |
| 13 |
stable for amd64. |
| 14 |
|
| 15 |
A caution, however. Until your whole system is rebuilt with the newer |
| 16 |
gccs, some C++ packages in particular may still link to the old |
| 17 |
versions. But it should at least be possible to ignore the old gccs for |
| 18 |
the moment (emerge --resume --skipfirst if necessary) and build |
| 19 |
everything else. If you're using FEATURES=buildpkg, it's easy enough to |
| 20 |
unmerge a package, see if anything breaks (run revdep-rebuild and see if |
| 21 |
there's anything that needs rebuilt, and hope it rebuilds fine), and |
| 22 |
remerge the binpkg if necessary. That's what I'd do. |
| 23 |
|
| 24 |
If you're not running FEATURES=buildpkg, I'd suggest you consider it. |
| 25 |
Right before a system-wide rebuild is a great time to turn it on. =:^) |
| 26 |
But if you're not, you can use quickpkg to create a binpkg of a |
| 27 |
particular package before removing it for testing. That way you still |
| 28 |
get the binpkg, and can remerge it if necessary, if you find you still |
| 29 |
need it. |
| 30 |
|
| 31 |
Anyway... after updating gcc to 4.3.2-r3 if you don't have it, and gcc- |
| 32 |
config-ing to it, you could emerge --emptytree @system @world so |
| 33 |
everything is built with it, and then unmerge older gcc versions, |
| 34 |
including the 4.1.2 that's giving you issues ATM. |
| 35 |
|
| 36 |
FWIW, on ~amd64, the only gcc I have currently installed is 4.4.1, as I |
| 37 |
unmerged earlier versions after I had rebuilt the entire system with it. |
| 38 |
I do remember having some issues rebuilding earlier gccs at one point, |
| 39 |
but with the entire system (other than those gccs) building with 4.4.1, I |
| 40 |
was able to unmerge them instead of rebuild them. |
| 41 |
|
| 42 |
Of course, I always do --update --deep --newuse, generally a couple times |
| 43 |
a week, and revdep-rebuild and --depclean afterward, to make sure the |
| 44 |
system stays consistent and keep the cruft to a minimum. If you've let |
| 45 |
it build up by not regularly using --update --deep and not regularly |
| 46 |
doing --depcleans and revdep-rebuilds, you are likely to have quite some |
| 47 |
problems getting the system back in shape, as there will be quite some |
| 48 |
cruft buildup to clean out, and doing it incrementally as the updates |
| 49 |
show up is MUCH easier than letting it buildup and trying to do it all at |
| 50 |
once. |
| 51 |
|
| 52 |
-- |
| 53 |
Duncan - List replies preferred. No HTML msgs. |
| 54 |
"Every nonfree program has a lord, a master -- |
| 55 |
and if you use the program, he is your master." Richard Stallman |
Archives