"John P. Burkett" <burk...@uri.edu> posted 1244553079.25061.91.ca...@microway, excerpted below, on Tue, 09 Jun 2009 09:11:19 -0400:
> On Tue, 2009-06-09 at 07:03 +0000, Duncan wrote: >> >> Try gcc-config, then. >> > 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 Yes, that's what I expected at this point. Good, we're getting somewhere! =:^) > 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 > 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. Now you see why I was initially trying to fix it with that. =:^) > Firefox and Thunderbird now work :-) Hallelujah! > 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? Unfortunately, I don't happen to use anything needing fortran here, so I don't have the same level of experience troubleshooting it as I do with normal gcc/g++. Therefore, I can't offer specific help on it, but perhaps general Gentoo and library level help will do... or maybe not. I guess we'll see. I believe libfortran.so is to fortran what libstdc++ is to C++. As such, I believe it's related to gcc. Meanwhile, gcc has the USE=fortran USE flag. When you remerged gcc, was that flag on or off? If it was off, I think we have our problem and solution. If it was and is still on... that's a problem. Next, I'd try equery, again. equery belongs libfortran.so.1 . Also try libfortran.so (without the .1) and if it shows up, see where it's pointing. Double-check the filesystem and see if the files are there (no, I don't know specifically where "there" should be, as I don't use fortran, equery will tell you if it knows a package containing it, else I'm not sure), either to match what equery says, or possibly, orphan files if equery doesn't know about them. Again, since I don't need fortran, I'm not sure how it's handled, but there's a fair chance there's some fortran selector tool, eselect fortran, or fortran-config, or some such, that allows you to switch between fortran versions, just like gcc-config allows you to switch between gcc versions. If equery is showing files and the libfortran.so.1 file is indeed actually there, but the symlink from libfortran.so to libfortran.so.1 (or whatever) is missing, this is what I'd investigate next, trying to find out if there's some selector for it that needs reset to point at the new version. > 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) Yes, indeed, that looks reasonable. (FWIW, as I'm on ~amd64, I'm probably using a newer gentoolkit, with slightly different semantics, thus the lack of gcc-config, etc, in my listing. I know it used to list it, and it lists it if I say equery list gcc-config, but it doesn't list gcc-config under plain gcc any more. I was actually surprised when I didn't see it listed, when I posted earlier, but there were other more important things we were worried about. But anyway, don't worry about that inconsistency, as I have gcc-config too. Presumably gccmakedep is missing here for a similar reason, I don't have it installed, but that's likely because I'm running a newer xorg than you, or for other system-specific reasons.) > man is working again :-> Good! I was somewhat worried there for a bit. It was certainly fixable, whatever the problem, but if gcc-config and/or a gcc rebuild hadn't worked, the fixes would have started getting much more complex, the sort of thing one does NOT want to be trying to do remotely, and if man's broken, things are getting bad enough it maybe time to start looking at drastic solutions such as extracting a stage tarball to get to a known working state in ordered to properly fix the system. Glad it didn't get to that point! >> 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 > 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. FWIW, I've never found eix particularly useful, here. I believe esearch is a less powerful (read less complex to work with as well, the reason I use it) replacement for part of it. Other functionality is provided by other tools. But if you find eix helpful and either know how to work it, or take advice from folks that find it helpful and know how to work it, great. Don't uninstall it there just because /I/ don't find it helpful here! But the general routine, sync, update system, update world, run revdep- rebuild, is a very solid one. > From now on I'll try to follow your good example of upgrading twice a > week. That's simply personal preference, because as I explained, it allows me to deal with things in smaller bites. Once a week is fine, as long as it's relatively consistent. But if you find the smaller bites of twice a week or even daily updates useful as I do, that's great too! > 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. Depclean is interesting. Honestly, getting the system cleaned up if you haven't been doing it routinely will be difficult, and may result in a bit of breakage until you get what you need in world, so depclean isn't trying to remove it. For that reason I would not feel right forcing it on anyone. OTOH, once you get the system in a consistent state and are doing depcleans routinely, it becomes just another step in the process, and because there was nothing left in its list at the end of your last update session, any changes to that status are MUCH MUCH easier to deal with because they happen one at a time and it's often obvious what caused the change and why. So it's up to you. No question, there'll be some pain getting the system into a consistent state on the package-removal side (which is what depclean does) as well as the package addition and update side, and that pain isn't going to be worth the hassle for some. OTOH, for those who either do it from the beginning, or work thru that initial period of pain to the point of system consistency, and then keep it there, it /does/ result in a cleaner, more consistent and troublefree system. To depclean or not is thus really a question of system management and adminstration style, whether you mind extra cruft along for the ride, or not, and which you'd prefer to deal with, the pain of dealing with extra cruft as you get rid of it immediately, or the pain of carrying it along until at some point, bits of it cause other problems. Regardless, tho, you still have a problem or two on the package update and addition side to worry about, namely, that fortran problem, at least, before you can even properly think of trying to do anything about the package and cruft cleanup side. Another similar issue is the "to --deep (-D) or not to --deep" question. Here, it's personal policy to always use --deep, simply because I want the latest version of dependencies too, even at the additional expense of what would otherwise be not strictly necessary updates and perhaps revdep- rebuilds as well. My argument is that again it's a cruft issue. In addition to the benefits of the new versions, knowing I always have the latests versions at my stability level (~arch for me, stable for those that choose it) means less issues with older versions perhaps not as likely tested either upstream or by Gentoo devs (and for stable users, by ~arch users before them). OTOH, this is at the acknowledged expense of having to merge perhaps four or five versions of various libraries, plus rebuilds of packages that depend on them if necessary (as caught by revdep-rebuild), for every single update a user NOT doing --deep might have. I prefer knowing the entire system, including deep dependencies, are on the latest version available, thus killing the cruft. Others may prefer the "if it works, don't fix it" approach, avoiding unnecessary package turnover for what's likely very little gain. Again, it's purely a system administration strategy issue, with benefits and negatives to either approach taken. It's your system so it's your choice. =:^) Finally, if you don't have it enabled, DO give some consideration to the FEATURES=buildpkg feature. Had you had it enabled when you merged that old gcc, when you removed it and things broke, you could have simply remerged it from binpkg temporarily, fixing whatever broke before trying to unmerge it again. Not having to recompile such big packages can be a REAL timesaver and even major system-saver when you suddenly find stuff like man breaking, and the system seems to be falling down around your ears! -- 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
