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

[Duncan]

Travis <address@hidden> posted
address@hidden, excerpted below, on  Mon, 25
Aug 2008 15:54:01 -0700:

>> On Mon, 25 Aug 2008 21:30:12 +0000, Beso wrote:
>>
>>> hi, i've just updated to pan 0.133 and now i get the error of missing
>>> /usr/lib/libstdc++.so.6. the problem is that this file seems to be
>>> libstdc++ 3.4. i'm on gentoo unstable. is there anyone who can help
>>> out?! maybe duncan...
>>>
>>> thanks
>>
>> Duncan is going to yell at you for sending html to the list ;o) so I'll
>> try to answer for him.
> 
> I was going to say something but thought Duncan would be all over it
> like stink on.......you know what.

Just got home from work... this all happened while I was sleeping, or at 
work, so I missed all the fun! =8^)

[reformatted for posting]

equery b -f libstdc
[ Searching for file(s) libstdc in *... ]

sys-devel/gcc-4.3.1-r1 
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/libstdc++.so ->
libstdc++.so.6.0.10)

sys-devel/gcc-4.3.1-r1
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/libstdc++.so.6 ->
libstdc++.so.6.0.10)

sys-devel/gcc-4.3.1-r1
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/libstdc++.so.6.0.10)

sys-devel/gcc-4.2.4
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/libstdc++.so.6 ->
libstdc++.so.6.0.9)

sys-devel/gcc-4.2.4
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/libstdc++.so.6.0.9)

sys-devel/gcc-4.2.4
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/libstdc++.so ->
libstdc++.so.6.0.9)


As the others suggested, your libstdc++ 3.4 (which is probably .so.5.*) 
is likely a gcc 3.4 compatibility library, assuming you don't have a 
gcc-3.4.x still merged.  Either that or it may be an orphaned version.  

The libstdc++.so.6.* versions are going to be part of your various 
gcc-4.x packages.  As such, they'll be in /usr/lib/gcc/* directories as 
seen above).  gcc-config will switch them in and out of view, but the 
problem is rather more complex than that.

In addition to what revdep-rebuild does for ordinary packages, for the 
libstdc++ problems, there's the fix_libtool_files.sh script.  I expect 
running this with the appropriate parameter (see below) will fix your 
problem.

The problem is this.  When you compile a c++ based library, libtool sets 
up the *.la file pointing at the currently selected gcc's libstdc++.  
Then you update gcc and the *.la files don't always get properly updated 
to point to the new libstdc++ as well as the old one, with it.  I think 
it runs the fix_libtool_files.sh script, but between gcc-config and the 
timing of gcc to the various library installs, it doesn't always properly 
update all of the *.la files.

What the script does is take the /old/ gcc version you hand it on the 
command line, searching for every occurrance of it in the *.la files, 
ensuring that they also have an entry for the current gcc's libstdc++.  
If they don't, it adds one (note that it doesn't remove the old one, 
which is fine even if that version is later unmerged, as long as it also 
points to the new one).

The point to remember is to feed the script the /old/ version, the one 
causing problems, not the current version.  Once you do that, you should 
be fine.  The error should tell you the version that wasn't found, tho 
you'll probably have to run pan from a terminal window in ordered to see 
it.

Very occasionally, the script will miss some *.la file somewhere.  It's 
possible to do a grep for the troublesome version and get a listing of 
all the *.la files containing it, and check them yourself, if necessary.

There's another, often easier but not always workable solution as well.  
In /most/ cases, not all but most, the *.la files aren't really needed at 
all and can actually be deleted rather than fooling with trying to edit 
them -- they cause more trouble than they are worth.  I don't grok the 
technical details but the exceptions tend to be stuff like plugins that 
are loaded somewhat differently from regular shared libraries.  Due to 
the way they are loaded, they /do/ often require the *.la files.

Thus, one option if you end up having to track down a problem with them 
manually is to /move/ the files in question to a different location out 
of the libsearch path (I like to use a dir named remove-<date> or 
similar), go about your business, and if something protests that it can't 
find one of those libraries or a plugin fails to work, try moving the 
associated *.la file back.  Later, as you come upon that directory again, 
you can decide if enough time has passed to safely delete it or not.

Another alternative, if you are using FEATURE=buildpkg at least, is to 
simply delete the *.la files, knowing you can always either remerge the 
binpkg or simply extract the *.la file right from the tarball, if 
necessary.  That way you don't have to worry about moving the *.las and 
deleting them later.  Since they aren't often used and you have an 
archived copy of them in the binpkg if necessary, just delete 'em.

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