Summary: | app-portage/eix-0.7.6 - generating eixrc fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Covington <covracer> |
Component: | Current packages | Assignee: | Martin Väth <martin> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | genstef, gentoo.org |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Christopher Covington
2006-10-07 01:37:38 UTC
This is not a bug of eix but an indication that something went wrong with the compiler upgrade on your system. Something in your system still points to the obsolete compiler library /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so.6 which shouldn't be the case after the upgrade to gcc-4.1. See e.g. http://forums.gentoo.org/viewtopic-t-502550-highlight-.html I read through the forum thread but I don't think many of the possible diagnoses apply in my case. # find / -wholename "*i386-pc-linux-gnu/3.4.6*" [nothing] # gcc-config -l [1] i686-pc-linux-gnu-3.4.4 [2] i686-pc-linux-gnu-3.4.4-hardened [3] i686-pc-linux-gnu-3.4.4-hardenednopie [4] i686-pc-linux-gnu-3.4.4-hardenednopiessp [5] i686-pc-linux-gnu-3.4.4-hardenednossp [6] i686-pc-linux-gnu-4.1.1 * I recently got rid of eselect-compiler as it was blocking an update. Should I run revdep-rebuild? I'm not certain if this is a dupe of #120469. I switched compilers like a month ago. (In reply to comment #2) > > # find / -wholename "*i386-pc-linux-gnu/3.4.6*" You switched from a different compiler version, of course, so you won't find that version, but I think you will be able to put your correct 3.4.4 instead in the thread. Did you try e.g. fix_libtool_files.sh 3.4.4? Roughly speaking: You will have to find out which files on your system still contain the obsolete references, and you have to reemerge the corresponding packages; for config-files it may be enough to remove resp. edit them (fix_libtool_files.sh does this for the *.la-files - maybe this is enough). You may want to use something like grep -Rl "686-pc-linux-gnu/3.4.4" /etc /usr /lib* to find further files. Of course, this will probably show you many files from gcc-3.4.4, so you might want to uninstall gcc-3.4.4 first (you can quickpkg it if you want it later again). I have the same problem with old files from gcc-3.4.6 hanging around. "fix_libtools_files.sh 3.4.6" did not fix the problem. Emerging libstdc++-v3-3.3.6 did not help either. The key is "CXXABI_1.3.1". Whatever supplies that is what need to be in place when eix-0.7.6 is emerged. Seems like a missing dependency. I was able to emerge eix-0.7.6 after an "emerge -C libstdc++-v3", which removes the old stdc++ compatibility support. Perhaps new versions of eix should block against that package. FWIW: According to 'objdump /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8' showed "CXXABI_1.3.1" is in the gcc-4.1.1 libraries. The bug appears to be that the old libstdc++ support is able to distract the eix config script from checking that far into the C++ support. I had gcc-4.1.1 selected during previous failures, but it wasn't visible to the eix compile. (In reply to comment #4) > The key is "CXXABI_1.3.1". No, it is not. The key is that the wrong library version is used (namely in this case that of gcc-3.4.4). If the compiler and libraries were configured correctly, it should not be possible that a reference to that version is produced (certainly, no such reference is hard-coded into the eix autotools/make - which BTW is rather standard). All people with this problem seem to have used eselect-compiler - probably this has created some wrong references and did not delete them (and gcc-config either modifies other references than eselect-compiler or is even caused to malfunction by the references of eselect-compiler). Of course, unmerging eselect-compiler does not fix this bug, since unmerging does not modify the files/links which eselect-compiler has modified. Moreover, files in /etc/... are not removed by unmerging anyway. A first step might consist in eliminating the references to 3.4.4 in /etc/eselect/*, /etc/env.d/*, and in /etc/ld.so.conf (and to call env-update and source /etc/profile afterwards - re-select your compiler with gcc-config to check that the reference is *not* created again in these files). However, if this does not help or if there is no such reference then you really have to unmerge the old gcc and check the whole remaining system where there are still references - there will not be many, and one of them must be the cause. (In reply to comment #5) > I was able to emerge eix-0.7.6 after an "emerge -C libstdc++-v3", Don't get fooled by this. Perhaps this is a cure for the symptom but not of the cause: The problem is not the old libstdc++.so.5 but that the wrong 3.4.4/libstdc++.so.6 library is referenced instead of 4.1.1/libstdc++.so.6. BTW, on my system, everything works very well with libstdc++-v3 installed. (In reply to comment #5) > I was able to emerge eix-0.7.6 after an "emerge -C libstdc++-v3", which removes > the old stdc++ compatibility support. Perhaps new versions of eix should block > against that package. > Works for me.OT: I find it weird that "emerge -uDN world" wants to reemerge libstdc++-v3 but "equery depends libstdc++-v3" returns no results. (In reply to comment #9) > Works for me. As I told you, this probably only cures the symptom. Anyway, should I closed the bug now? > OT: I find it weird that "emerge -uDN world" wants to reemerge > libstdc++-v3 but "equery depends libstdc++-v3" returns no results. IIRC, equery does not consider dependencies triggered by useflags. (In reply to comment #10) > As I told you, this probably only cures the symptom. Anyway, should I closed > the bug now? I suppose so, although I still don't understand the "right way" to fix this issue. The problem came back after some emerge updates. gcc-3.4.6 support got pulled back in, and the successfully compiled eix stopped working, again complaining about missing "CXXABI_1.3.1". I was again able to fix the problem by making /usr/lib/gcc/$(CHOST)/3.4.6 unfindable. I found the root cause of the problem. The folowing lines appeared in my /etc/ld.so.conf: /usr/lib/gcc/i686-pc-linux-gnu/3.4.6 /usr/lib/gcc/i686-pc-linux-gnu/4.1.1 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6 When I removed the first reference to 3.4.6, and did a "ldconfig", eix started working again, even with the compiler directory in its proper place. I don't know how that series of lines got arranged like that. I didn't do it. So perhaps this bug should become a report of some inconsistencies after a gcc upgrade, preventing CXXABI_1.3.1 from being visible to apps that need it. Further investigation shows that the presence of a stale /etc/env.d/05compiler file is what provided the old compiler reference in /etc/ld.so.conf prior to the one in /etc/env.d/05gcc. The erroneous file belongs to "eselect-compiler", and is easily corrected. Since I no longer have eselect-compiler emerged, I removed it. *** Bug 150986 has been marked as a duplicate of this bug. *** |