I did revdep-rebuild and things went fine. When I did --depclean, It removed many necessary packages. And I can not even complete running "emerge system", it fails on one of the packages due to missing alocal !
I can not even run mutt, as lynx is not there and can not install it as well. I run this type of things before going to bed, as it takes time. I should change this habit, and spend time on it when I am not tired. :) I will look into this tonight, or maybe on the weekend. I may have to spend many hours to fix this. Normally I run "emerge --update --deep --newuse world" every two weeks, but I haven't done this for more than 2 months. I don't this should be an issue. On Tue, Oct 13, 2009 at 11:39 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Mansour Al Akeel posted on Tue, 13 Oct 2009 10:25:15 -0300 as excerpted: > >> I lost the output from the previos build, and unable to regenerate the >> issue after fooliwnf libxcb update guilde. But now I am stuck with >> another error, when bulllding gcc. >> >> >> /var/tmp/portage/sys-devel/gcc-4.1.2/ > > gcc-4.1.2 ? gcc 4.1 is a bit outdated. You /may/ be able to simply > unmerge it. What versions of gcc do you have installed, anyway? It's > likely you have a 4.3 version, as gcc-4.3.2-r3 is the latest keyworded > stable for amd64. > > A caution, however. Until your whole system is rebuilt with the newer > gccs, some C++ packages in particular may still link to the old > versions. But it should at least be possible to ignore the old gccs for > the moment (emerge --resume --skipfirst if necessary) and build > everything else. If you're using FEATURES=buildpkg, it's easy enough to > unmerge a package, see if anything breaks (run revdep-rebuild and see if > there's anything that needs rebuilt, and hope it rebuilds fine), and > remerge the binpkg if necessary. That's what I'd do. > > If you're not running FEATURES=buildpkg, I'd suggest you consider it. > Right before a system-wide rebuild is a great time to turn it on. =:^) > But if you're not, you can use quickpkg to create a binpkg of a > particular package before removing it for testing. That way you still > get the binpkg, and can remerge it if necessary, if you find you still > need it. > > Anyway... after updating gcc to 4.3.2-r3 if you don't have it, and gcc- > config-ing to it, you could emerge --emptytree @system @world so > everything is built with it, and then unmerge older gcc versions, > including the 4.1.2 that's giving you issues ATM. > > FWIW, on ~amd64, the only gcc I have currently installed is 4.4.1, as I > unmerged earlier versions after I had rebuilt the entire system with it. > I do remember having some issues rebuilding earlier gccs at one point, > but with the entire system (other than those gccs) building with 4.4.1, I > was able to unmerge them instead of rebuild them. > > Of course, I always do --update --deep --newuse, generally a couple times > a week, and revdep-rebuild and --depclean afterward, to make sure the > system stays consistent and keep the cruft to a minimum. If you've let > it build up by not regularly using --update --deep and not regularly > doing --depcleans and revdep-rebuilds, you are likely to have quite some > problems getting the system back in shape, as there will be quite some > cruft buildup to clean out, and doing it incrementally as the updates > show up is MUCH easier than letting it buildup and trying to do it all at > once. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > >