Recently, the emul maintainer Pacho Ramos (pacho@gentoo.org) removed from app-emulation/emul-linux-x86-compat the libraries in /usr/lib32/libstdc++-v3/, namely /usr/lib32/libstdc++-v3 /usr/lib32/libstdc++-v3/libstdc++.so.5 -> libstdc++.so.5.0.7 /usr/lib32/libstdc++-v3/libstdc++.so.5.0.7 on the grounds that these are (or should be) duplicated by sys-libs/libstdc++-v3-3.3.6 which provides /usr/lib32/libstdc++.so.5 -> libstdc++.so.5.0.7 /usr/lib32/libstdc++.so.5.0.7 Unfortunately sys-libs/libstdc++-v3-3.3.6 does not contain the full suite of libraries. Specifically, it does not contain the GLIBCPP_3.2* libraries. Compare: % strings /usr/lib32/libstdc++.so.5.0.7 | grep GLIBC GLIBC_2.0 GLIBC_2.3 GLIBC_2.1 GLIBC_2.1.3 GLIBC_2.2 GLIBCPP_FORCE_NEW to % strings /usr/lib32/libstdc++-v3/libstdc++.so.5.0.7 | grep GLIBC GLIBCPP_3.2 GLIBCPP_3.2.1 GLIBCPP_3.2.2 GLIBCPP_3.2.3 GLIBCPP_3.2.4 GLIBC_2.0 GLIBC_2.3 GLIBC_2.1 GLIBC_2.1.3 GLIBC_2.2 GLIBCPP_FORCE_NEW The emulation libraries contain the GLIBCPP_3.2* libraries, whereas the native libraries do not. This is only a problem with the 32-bit libraries. The 64-bit libraries do contain GLIBCPP_3.2*. As an example of how a legacy program fails to compile: ... /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../lib32/libpfutil.so: undefined reference to `vtable for std::basic_streambuf<char, std::char_traits<char> >@GLIBCPP_3.2' ... It appears probable that the full set of libraries can be generated by a corrected set of configure flags applied to sys-libs/libstdc++-v3-3.3.6 Could that be done? Pacho Ramos believes that this is the correct solution, rather than keeping the libraries in an emulation package. Thanks, Andrew Hamilton
those arent libraries, they're symbol versions gcc-3.3.6 doesnt do it either for the 32bit multilib
*** This bug has been marked as a duplicate of bug 304239 ***
