"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 * 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 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) 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. 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. 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. -- 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
