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 |