On Tue, 2009-06-09 at 07:03 +0000, Duncan wrote: > "John P. Burkett" <burk...@uri.edu> posted 4a2db2a9.80...@uri.edu, > excerpted below, on Mon, 08 Jun 2009 20:54:01 -0400: > > > Thank you, Duncan, for the explanation and suggestion. > > > > Doing "fix_libtool_files.sh 4.2.0" or "fix_libtool_files.sh 4.2" > > elicited the following response: > > > > * Scanning libtool files for hardcoded gcc library paths... gcc-config: > > error: could not run/locate 'gcc' :0: assertion failed: (gcc > > -dumpversion) | getline NEWVER) > > Eew, OK, you're problem's a bit deeper than that. FWIW, > fix_libtool_files.sh is normally required for compiling stuff. I guess I > didn't read so well and thus failed to notice the obvious, that you are > having trouble /running/ stuff too. That's a bit different and obviously > a more serious issue, tho hopefully as easily fixed. > > Try gcc-config, then. What I'm guessing happened is that you unmerged > the old gcc without gcc-config-ing to the new version, so now all the > pointers are pointed at nothing. > > gcc-config -l (--list-profiles) will give you a list of the versions it > thinks it has installed. You can then (as root) tell it to switch to one > of them using its number. For instance, here's what I have here: > > gcc-config -l > [1] x86_64-pc-linux-gnu-4.3.3 > [2] x86_64-pc-linux-gnu-4.4.0 * > Thank you, Duncan. When I did "gcc-config -l" the response was as follows: * gcc-config: Active gcc profile is invalid! [1] x86_64-pc-linux-gnu-4.3.2
> The *-ed one, 4.4.0, is active. As root, I could switch to 4.3.3 using > it's position, as: > > gcc-config 1 > > or I could switch using the profile name (here switching back to 4.4): > > gcc-config x86_64-pc-linux-gnue-4.4.0 When I did "gcc-config 1" the response was * Switching native-compiler to x86_64-pc-linux-gnu-4.3.2 ... * Your gcc has a bug with GCC_SPECS. * Please re-emerge gcc. * http://bugs.gentoo.org/68395 >>> Regenerating /etc/ld.so.cache... [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * # source /etc/profile Next I did "emerge gcc". That seems to have succeeded. The response included the following: * Messages for package sys-devel/gcc-4.3.2-r3: * If you have issues with packages unable to locate libstdc++.la, * then try running 'fix_libtool_files.sh' on the old gcc versions. >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. Firefox and Thunderbird now work :-) However, some other applications are still not starting. When I try to start R, the response is /usr/lib64/R/bin/exec/R: error while loading shared libraries: libgfortran.so.1: cannot open shared object file: No such file or directory. Trying to start octave elicits the response octave: error while loading shared libraries: libgfortran.so.1: cannot open shared object file: No such file or directory The common theme is lack of libgfortran.so.1. Any suggestions about how to fix that problem? > > > Since it's apparently screwed up ATM, you may have to do it using the -f > (--force) option, which regenerates all the files even if it thinks they > are fine. > > If that doesn't do it, you may need someone who really understands what's > going on to help, probably one of the gentoo/amd64 devs or ATs (arch- > testers). But hopefully that does it. > > > To check what newer version is installed, I did "emerge --search gcc". > > The response included the following lines: > > FWIW, --search just shows you the latest installed. For slotted packages > such as gcc, you may have more installed. If you have gentoolkit > installed, you can use equery to get the full list, using equery list > <pkgspec>, which lists the packages matching the parameter, as so: > > equery list gcc > * Searching for gcc ... > * installed packages: > [I--] [ ~] sys-devel/gcc-4.3.3-r2 (4.3) > [I--] [ ~] sys-devel/gcc-4.4.0 (4.4) Now when I do "equery list gcc" the response looks good: [ Searching for package 'gcc' in all categories among: ] * installed packages [I--] [ ] sys-devel/gcc-4.3.2-r3 (4.3) [I--] [ ] sys-devel/gcc-config-1.4.1 (0) [I--] [ ] x11-misc/gccmakedep-1.0.2 (0) > > > FWIW, equery has other modes of operation as well. equery belongs <file> > tells you which package, if any, "owns" a particular file or directory. > (Note that with directories, a package "owns" it if it has files in it or > a subdir. Thus, a LOT of packages "own" /usr/, because they all have > files in various /usr/ subdirs.) > > equery files <pkgspec> lists the files belonging to a particular > package. equery depends <pkgspec> lists all the packages that depend on > the particular package in question (with USE conditional dependencies > listing the USE flag creating the dependency). equery depgraph <pkgspec> > lists the packages a particular package depends on -- multiple layers > deep, so sometimes the --depth=n parameter for it comes in handy to limit > the output. There's also equery hasuse and equery uses, as well. > > For equery list, the default (-i --installed) lists installed packages, > but there's also -p (--portage-tree) and -o (--overlay-tree) that can be > searched, if you provide the appropriate switch. Also, most of equery's > actions have a regex option, if you need a bit more flexibility > specifying the file/pkgspec. See the manpage (when you can) or --help > output, for more. > > > Doing "emerge --empty-tree world" evoked the following response: emerge: > > error: no such option: --empty-tree > > My fault. I typed without double-checking. It's --emptytree without the > hyphen between empty and tree. Sorry. But as Nikos mentions, -e is the > short form. > > > Trying to check the available options, I did "man emerge" but just got > > groff: /lib/libgcc_s.so.1: version `GCC_4.2.0' not found (required by > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6) > > ... As I said, more serious than I originally thought. Hopefully gcc- > config can straighten it out. man is working again :-> > > FWIW, most commands support --help, which is shorter than the manpage, > normally limited to a single console terminal page if at all possible, > but that can often be enough. It wouldn't have helped here, however, as > that parameter's not used enough to put it in the short-form --help > output. > > > It looks as if the problem affecting Firefox and Thunderbird also > > affects man. > > It's not going to be of much help at the moment, but FWIW, upgrades do > tend to go much smoother if you don't stay away from them so long. > Personally, I try to do them twice a week so there's never too huge a > list, and even when a kde upgrade comes out, while it might be a bunch of > packages, it's almost all /just/ kde, not gcc and baselayout and portage > and a whole bunch of other stuff all at once! However, that's admittedly > a bit obsessive/compulsive. Still, I'd recommend trying to upgrade every > month to avoid getting too far out of date, and certainly not going > longer than three months, as at that point, you're just making it much > much harder to upgrade when you do, because you're so far out. Gentoo > /does/ try to keep a workable upgrade out to at least a year, but > honestly, longer than three months, and there's few enough people doing > it that infrequently that it's not well tested, and you WILL thus run > into more problems than you will staying closer to the Gentoo > mainstream. Gentoo simply isn't the best choice for people that want to > upgrade once a year or less, and then forget about it. There are other > distributions that work better for that sort of installation. OTOH, > Gentoo is one of the best choices for "obsessive compulsive" types like > myself, that like its rolling update style, updating far more frequently > (best is once a month or more often, as I said) than the ordinary binary > distribution does. My weekly routine has been to do eix-sync emerge -D -uav system emerge -D -uav world When the responses have suggested doing "revdep rebuild", I've done so. >From now on I'll try to follow your good example of upgrading twice a week. Whether I should add "emerge --depclean" to my upgrade routine is not so clear to me. Perhaps it should only be used by people who know more than I do. > > I do hope gcc-config does it for you. Otherwise, I'm getting a bit > worried, as if man is broken, it's reaching pretty far into your system. > Please post updates as you have them, because I /am/ a bit worried, now. > Thanks again for your help. Best regards, John
