Travis <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
