The latest emul-linux-x86-compat-1.0-r2 breaks zsnes. With r2 I get the following error when running zsnes: zsnes: /usr/lib32/libstdc++.so.6: version `CXXABI_1.3.1' not found (required by zsnes) Downgrading to r1 lets zsnes work. Recompiling zsnes makes no difference.
This is using zsnes-1.42.
*** Bug 160336 has been marked as a duplicate of this bug. ***
What was the previous package you were on? Because emul-linux-x86-compat has never provided CXXABI_1.3.1 as far as I can tell. It only provides CXXABI_1.3. It sounds like you rolled your own compiler or did something funky. Provide emerge --info to all bugs.
the problem is that previously, zsnes would [correctly] use the libstdc++.so.6 from gcc now that it's installed into /usr/lib32/, zsnes is trying to use that one i dont see why emul-linux-x86-compat should be supplying any libstdc++.so from gcc-3.3.x or gcc-3.4.x+ (libstdc++.so.[56]) since the toolchain takes care of this
Same error and same solution here (downgrading to =app-emulation/emul-linux-x86-compat-1.0-r1).
downgrading is not the correct solution delete /usr/lib32/libstdc++.so.[56]*
Deleting /usr/lib32/libstdc++.so.[56]* doesn't help. Now zsnes says it simply can't find the libraries. zsnes: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Is it the case that those files need to be removed and gcc remerged?
run, run `ldconfig` to rebuild your cache
*** Bug 163223 has been marked as a duplicate of this bug. ***
Fixed thx
[code] 29 Jan 2007; Timothy Redaelli <drizzt@gentoo.org> emul-linux-x86-compat-1.0-r3.ebuild: Install libstdc++.so.5 if gcc 3.4.* is not installed. [/code] well, this breaks mozilla-firefox-bin. see: http://forums.gentoo.org/viewtopic-t-536068-highlight-.html btw.. i have *both* installed, gcc 3.4.x *and* gcc 4..x, so now what? <g>
The fix is incorrect. libstdc++.so.5 is not provided by gcc-3.4.x or gcc-4.1.x. The latest compat lib broke mozilla-firefox-bin since libstdc++.so.5 does not exist on my machine anymore. The fix is proper for libstdc++.so.6. But libstdc++.so.5 is provided by gcc-3.3.x not any higher version.
Appear the original committed version of the ebuild was wrong and someone fixed it without rev bumping it.
*** Bug 164555 has been marked as a duplicate of this bug. ***
In fact I was correct when I opened the bug before. This fix is not correct and Spanky is wrong here. gcc-3.3.x -> libstdc++.so.5 gcc-3.4.x -> libstdc++.so.6 gcc-4.1.x -> libstdc++.so.6 The has_version check in the latest ebuild needs to be against gcc-3.3.x.
Fixed without a rev bump per Kugelfang.
Why was this change needed? (I'm trying to understand the 32/64bit thing going on here...) Why would a 32bit libstdc++.so.[56] in /usr/lib32/ be found by (what I am assuming is) a 64bit zsnes, and not the 64bit version (presumably) in /usr/lib64/libstdc++-v3/ or /usr/lib64/gcc/blah/blah/blah ?
no idea what you're talking about, i never said gcc-3.4.x or newer provided libstdc++.so.5 packages that need the older libstdc++ should be pulling in virtual/libstdc++ fix the broken packages, stop screwing with the compat packages
(In reply to comment #18) > no idea what you're talking about, i never said gcc-3.4.x or newer provided > libstdc++.so.5 > > fix the broken packages, stop screwing with the compat packages You are absolutely right. Fix the broken packages. Now, how about this.... root@ale ~ # revdep-rebuild -p --library=libstdc++.so.5 Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries using libstdc++.so.5 will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Checking dynamic linking... found /usr/lib32/libtiffxx.so.3.7.3 done. (/root/.revdep-rebuild_fb248503.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild_fb248503.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild_fb248503.5_order) All prepared. Starting rebuild... emerge --oneshot -p =app-emulation/emul-linux-x86-baselibs-2.5.5-r3 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-emulation/emul-linux-x86-baselibs-2.5.5-r3 Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. root@ale ~ # Hmmm........ The culprit is libtiffxx.so.3.7.3, from extactly the same package it tries to fix..., So at least that one needs to be recompiled with at least gcc-3.4.
(In reply to comment #18) > no idea what you're talking about, i never said gcc-3.4.x or newer provided > libstdc++.so.5 > > packages that need the older libstdc++ should be pulling in virtual/libstdc++ > > fix the broken packages, stop screwing with the compat packages > But, if a packages needs libstdc++.so.5 and pulls virtual/libstdc++, then I'll have gcc-3* installed for no reason?
if installing it gives you libstdc++.so.5, how exactly is that "for no reason"
app-emulation/emul-linux-x86-compat-1.0-r3 breaks mozilla-firefox-bin. Reverting to -r2 fixed the problem. Since I haven't had gcc-3.3.x on my system at least since Jan 2006 (if I've ever had it; there's no mention of gcc-3.3.x in my emerge.log) and since I've been running mozilla-firefox-bin successfully also since Jan 2006, I'm skeptical that the answer is "install gcc-3.3.x".
one of us has facts on their side, the other has vague descriptions and hints at failures provide some real data about your system
Not sure why this is still open, someone already made the has_version =sys-devel/gcc-3.4* to has_version =sys-devel/gcc-3.3* change in the ebuild, as the e-build thought gcc 3.4 provided libstdc++.so.5, when gcc3.4 provided only libstdc++.so.6 ... Appears fixed to me, as my firefox-bin is working these days. Just emerge --sync and emerge --oneshot emul-linux-x86-compat
that's a midway hack that probably works for most people, yes ... but the emul-* packages themselves are just one big hack so it isnt like putting hacks in them is that big of a deal
we don't support 3.3 anyway, fixed properly with a block
*** Bug 184212 has been marked as a duplicate of this bug. ***
*** Bug 189927 has been marked as a duplicate of this bug. ***
