Darwinia needs libstdc++.so.5, which is not included in the latest emul-linux-x86-compat (20091231). Either an older version should forced in darwinia ebuild (20081109 is fine) or libstdc++.so.5 should be readded to emul-linux-x86-compat-20091231. Reproducible: Always Steps to Reproduce: 1. emerge darwinia in ~amd64 2. run it 3. Actual Results: /opt/darwinia/lib/darwinia.bin.x86: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
Indeed, emul-linux-x86-compat should provide libstdc++.so.5 from GCC 3.3.x, all of these: http://tinderbox.x86.dev.gentoo.org/misc/rindex/app-emulation/emul-linux-x86-compat Need it. It's even mentioned in the description of the package.
This shouldn't occur if you are using a multilib system as that lib is already provided by sys-libs/libstdc++-v3-3.3.6: $ equery b /usr/lib32/libstdc++.so.5.0.7 * Searching for /usr/lib32/libstdc++.so.5.0.7 ... sys-libs/libstdc++-v3-3.3.6 (/usr/lib32/libstdc++.so.5.0.7) Do you have it installed?
This is also explained in bug 288084
(In reply to comment #1) > Need it. It's even mentioned in the description of the package. > Is description says that it's for non-multilib systems ;-) and, in ebuild, the files are removed only on multilib systems (or maybe I am doing something wrong :-/): src_unpack() { emul-linux-x86_src_unpack if has_multilib_profile ; then rm -rf "${S}/usr/lib32/libstdc++.so.5.0.7" \ "${S}/usr/lib32/libstdc++.so.5" || die fi }
Maybe I could add a "multilib" USE flag making app-emulation/emul-linux-x86-compat RDEPEND on sys-libs/libstdc++-v3 when enabled (due multilib profile being used) and don't remove those files when running on a non-multilib profile But maybe there are better options :-/
(In reply to comment #5) > But maybe there are better options :-/ If virtual/libstdc++:3.3 that is sys-libs/libstdc++-v3 should bring libstdc++.so.5 in, then fine, we have to deal with it... Suggestion: USE="cxx" to RDEPEND of emul-linux-x86-compat with virtual/libstdc++:3.3 depend? IUSE="+cxx multilib" RDEPEND="!multilib? ( cxx? ( virtual/libstdc++:3.3 ) )"
I'm pretty sure that logic failed, so don't take my word for it. ;)
I would prefer to be sure people have always /usr/lib32/libstdc++.so.5.0.7 installed (that way we wouldn't need to rework every ebuild depending on emul-linux-x86-compat bumping them to EAPI=2 for getting emul package build with "cxx" flag) Then, I still prefer having a multilib USE flag also in emul-linux-x86-compat, that way: - If people are using a multilib profile, that USE flag will be enabled in both (app-emulation/emul-linux-x86-compat and sys-libs/libstdc++) and people will get libstdc++.so.5.0.7 from libstdc++ (since it will RDEPEND on libstdc++ when "multilib" USE flag is enabled) and the rest of libs from emul-linux-x86-compat. - If people are using a non-multilib profile, emul-linux-x86-compat won't rdepend on sys-libs/libstdc++ (since it will also be built without multilib support) and they will get that lib from emul package I will try to commit it (with a revbump probably) once I have enough time Regards :-)
*** Bug 301220 has been marked as a duplicate of this bug. ***
Should be solved with emul-linux-x86-compat-20091231-r1
(In reply to comment #10) > Should be solved with emul-linux-x86-compat-20091231-r1 It needs one more thing, actually: * QA Notice: The following shared libraries lack NEEDED entries: * /var/tmp/portage/app-emulation/emul-linux-x86-compat-20091231-r1/image/usr/lib32/libc.so.5 So there's some kinda QA thing for the latest -compat that needs fixin'.
It's a different problem and bug report (one minute please for finding it)
You are looking for bug 246332 ;-)
I still have the problem described here. My system has app-emulation/emul-linux-x86-compat-20091231-r1 (multilib) which misses any libstdc++.so.5: bogo lib # equery files emul-linux-x86-compat [ Searching for packages matching emul-linux-x86-compat... ] * Contents of app-emulation/emul-linux-x86-compat-20091231-r1: /etc /etc/env.d /etc/env.d/99libstdc++32 /usr /usr/lib32 /usr/lib32/ld-linux.so.1 -> ld-linux.so.1.9.11 /usr/lib32/ld-linux.so.1.9.11 /usr/lib32/libc.so.5 /usr/lib32/libg++.so.2.7.2 -> libg++.so.2.7.2.8 /usr/lib32/libg++.so.2.7.2.8 /usr/lib32/libstdc++-2-libc6.1-1-2.9.0.so /usr/lib32/libstdc++-3-libc6.2-2-2.10.0.so /usr/lib32/libstdc++-libc6.1-1.so.2 -> libstdc++-2-libc6.1-1-2.9.0.so /usr/lib32/libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so /usr/lib32/libstdc++.so.2.7.2 -> libstdc++.so.2.7.2.8 /usr/lib32/libstdc++.so.2.7.2.8 /usr/lib32/libstdc++.so.2.8 -> libstdc++.so.2.8.0 /usr/lib32/libstdc++.so.2.8.0 /usr/lib32/libstdc++.so.2.9 -> libstdc++.so.2.9.0 /usr/lib32/libstdc++.so.2.9.0 bogo lib #
Please open a different bug report reporting also "equery files sys-libs/libstdc++-v3", "emerge -pv sys-libs/libstdc++-v3" and "emerge --info" outputs
I had to recompile sys-libs/libstdc++-v3 because of a new use flag, that fixed it. Thanks!
