[Pan-users] Re: libstc++.so.6 missing

[Duncan]

Beso <address@hidden> posted
address@hidden, excerpted
below, on  Tue, 26 Aug 2008 10:55:36 +0200:

> i definitely have some problems with gcc... i have the libstdc++.so.6
> poiting to the 4.2.4 while the one i use for compilation is the 4.3.1.
> also i still have present in gcc-config the old removed versions. i
> usually don't use more than one versions of gcc but some packages still
> fail with gcc 4.3.1 due to the new gcc api changes not being implemented
> yet. do you think that the fix_libtool_files.sh script might help fixing
> this or do i need to do a manual cleanup of the system removing all the
> cruft that is present in the system?! for the moment i'll just try point
> the link to the correct location.

Did you ever have eselect-compiler and gcc-config-2.0 installed?  Some of 
that sounds like some of the mixups it left behind, that yes, had to be 
corrected manually.

BTW, what libstdc++.so.6 file (presumably symlink) are you actually 
referring to?  You haven't posted the absolute path, yet, 

Also note that I'm on a no-multilib profile here (I'm assuming you are 
talking about your amd64 machine, since I normally see you in the gentoo-
amd64 group/list).  The biggest reason to run multilib is to run 32-bit 
closed source apps, and since I won't install such things (I've mentioned 
before that I do have one old closed source DOS game, copyright 1993, 
that I still play in DOSBOS, but so I still run one, which I am enslaved 
to, to the degree that I've not gotten rid of it at least, but it's the 
only one, and I won't install others nor could I legally in most cases 
since I can't agree to the EULAs), I've little reason to run multilib.  
The only reason was so I could compile grub instead of having to rely on 
grub-static, but I decided that wasn't enough reason, so I went no-
multilib profile and I've been very glad I did; FAR less hassles as a 
result.  Anyway, multilib complexifies things considerably, so if you 
haven't killed it already and don't do any proprietaryware that you can't 
do without, certainly consider doing so.

Meanwhile, fix_libtool_files.sh /only/ worries about the *.la files.  If 
those aren't the problem, running it won't fix it.

What I'd do at this point would be manually remove the old gcc-config gcc 
profiles and after double-checking to make sure portage/$PM doesn't have 
a record of them that you can still unmerge, any remnants of old gccs you 
see in /usr/lib(64)/gcc-lib/*.

Then I'd run equery files gcc-config (or equivalent using 
$TOOL_OF_CHOICE), and compare the results to which gcc-config.  IIRC it 
moved awhile back and a few folks have found remnants of old versions 
(due to crash and restore from backup or similar such that the installed 
package database didn't match the reality on disk, I had that problem at 
one point and I was weeding out orphaned files for quite some time!) get 
run instead of the new version.  Obviously, that causes problems.  Of 
course, remove or if cautious, move and archive such troublesome bits you 
may find so they don't interfere with things.

Once you are sure the gcc-config that gets run when you type that in is 
the one actually installed by the package, try running gcc-config --force 
<profile>, toggling it back and forth between your current profiles a 
couple times.  Then run env-update.  Hopefully that will correct the 
problem and you won't have to do anything else manually.

At this point, I'd check /etc/ld.so.conf and see if it's still listing 
anything strange.  Since it's regenerated by env-update and you should 
have ran it in the last step, if there's anything weird still listed, 
it's coming from files in /etc/env.d, so that's the next place to check.  
Due to config-protect, it's possible stale files got left there when the 
package that installed them was unmerged.  Note that the gcc and binutils 
subdirs as well as their scripts in env.d itself are probably controlled 
by gcc-config and eselect binutils, so be careful modifying them directly 
at this point, but certainly check them.  Check all files for LDPATH 
entries among others, as those are what env-update puts into ld.so.conf.  
If you find something weird, check to see if the file it occurs in is 
owned by a package.  A quick equery belongs /etc/env.d should get you all 
the packages interested in the dir.  Of course, files that gcc-config and 
eselect binutils place there won't be owned by a package, but they should 
be obvious.  Similarly with java-config, if you have java installed.  
Other orphaned files may be suspect.  Consider moving them somewhere else 
for testing and ultimate deletion if they aren't needed.  Anything 
suspect in owned files here, well, that's a package issue I can't safely 
speculate about without at least knowing the package.

If that doesn't fully correct the problem, I'd dive into gcc-config 
itself, working thru what it did until I understood it well enough to 
execute the steps manually (or alternatively, place debug echos as 
necessary to verify what it's doing when you run it).  It may be that 
it's now messed up enough that it can't make sense of things on its own, 
and you need to figure out where it's going wrong and fix it.  (From your 
posts on gentoo-amd64, I trust parsing bash scripts isn't a problem for 
you.  If I thought it was, I'd be suggesting that you consider starting 
over from a stage file, but why do that when it's more fun and probably 
less hassle to track down and fix the problem yourself?  Right? =:^)

-- 
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