Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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. ***