[gentoo-amd64] Re: revdep-rebuild, Firefox, Thunderbird, GCC

[Duncan]

"John P. Burkett" <burkett@×××.edu> posted
1244553079.25061.91.camel@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