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