160335 2007-01-05 16:17 0000 emul-linux-x86-compat-1.0-r2 provides libstdc++.so which conflicts with gcc 2007-08-23 13:38:32 0000 1 1 1 Unclassified Gentoo Linux Games unspecified AMD64 Linux RESOLVED FIXED P2 normal --- 165270 1 njdoyle+bugs@gmail.com amd64@gentoo.org aikawarazuni@gmail.com brad@mainstreetsoftworks.com didier.fabert@free.fr jadamcze@utas.edu.au md401@srcf.ucam.org mkyral@email.cz onizuka92@free.fr rickard.narstrom@gmail.com vapier@gentoo.org njdoyle+bugs@gmail.com 2007-01-05 16:17:03 0000 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. njdoyle+bugs@gmail.com 2007-01-05 16:30:03 0000 This is using zsnes-1.42. nyhm@gentoo.org 2007-01-05 16:54:08 0000 *** Bug 160336 has been marked as a duplicate of this bug. *** cardoe@gentoo.org 2007-01-10 15:04:24 0000 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. vapier@gentoo.org 2007-01-10 17:09:48 0000 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 genzilla@boris64.net 2007-01-12 14:45:25 0000 Same error and same solution here (downgrading to =app-emulation/emul-linux-x86-compat-1.0-r1). vapier@gentoo.org 2007-01-12 15:42:42 0000 downgrading is not the correct solution delete /usr/lib32/libstdc++.so.[56]* njdoyle+bugs@gmail.com 2007-01-12 18:08:37 0000 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? vapier@gentoo.org 2007-01-12 18:33:12 0000 run, run `ldconfig` to rebuild your cache jakub@gentoo.org 2007-01-22 11:49:36 0000 *** Bug 163223 has been marked as a duplicate of this bug. *** drizzt@gentoo.org 2007-01-29 16:22:35 0000 Fixed thx sprockhoevel@web.de 2007-01-30 13:43:01 0000 [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> cardoe@gentoo.org 2007-01-30 15:17:34 0000 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. cardoe@gentoo.org 2007-01-30 15:29:48 0000 Appear the original committed version of the ebuild was wrong and someone fixed it without rev bumping it. jakub@gentoo.org 2007-01-30 18:16:17 0000 *** Bug 164555 has been marked as a duplicate of this bug. *** cardoe@gentoo.org 2007-01-30 19:32:23 0000 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. cardoe@gentoo.org 2007-01-30 20:32:20 0000 Fixed without a rev bump per Kugelfang. jadamcze@utas.edu.au 2007-01-31 00:47:10 0000 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 ? vapier@gentoo.org 2007-01-31 04:49:39 0000 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 ari@goron.de 2007-01-31 11:09:25 0000 (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. fedux@lugmen.org.ar 2007-01-31 13:52:09 0000 (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? vapier@gentoo.org 2007-02-01 04:34:52 0000 if installing it gives you libstdc++.so.5, how exactly is that "for no reason" vgivanovic@comcast.net 2007-02-10 18:42:31 0000 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". vapier@gentoo.org 2007-02-11 00:22:32 0000 one of us has facts on their side, the other has vague descriptions and hints at failures provide some real data about your system brad@mainstreetsoftworks.com 2007-02-11 01:15:05 0000 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 vapier@gentoo.org 2007-02-11 04:47:43 0000 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 blubb@gentoo.org 2007-02-11 23:05:05 0000 we don't support 3.3 anyway, fixed properly with a block jakub@gentoo.org 2007-07-04 18:57:57 0000 *** Bug 184212 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-08-23 13:38:32 0000 *** Bug 189927 has been marked as a duplicate of this bug. ***