revdep-rebuild complains about "broken /usr/lib/libAMDXvBA.so.1.0 (requires libstdc++.so.5)". Resulting in re-emerging ati-drivers but this does not solve the problem. I've tried emerging lib-compat but the version of libstdc++ is not the correct one. Reproducible: Always Steps to Reproduce: 1. emerge ati-drivers-8.552-r2 2. run revdep-rebuild 3. re-run revdep rebuild to see nothing has changed Portage 2.2_rc16 (default/linux/x86/2008.0/desktop, gcc-4.3.2, glibc-2.8_p20080602-r0, 2.6.27-gentoo-r4 i686) ================================================================= System uname: Linux-2.6.27-gentoo-r4-i686-Intel-R-_Core-TM-2_CPU_T5600_@_1.83GHz-with-glibc2.0 Timestamp of tree: Fri, 28 Nov 2008 17:19:01 +0000 app-shells/bash: 3.2_p48 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.5.2-r8 dev-util/cmake: 2.6.2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ " LANG="fr_FR.ISO-8859-15" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/pro-audio /usr/local/portage/layman/java-overlay /usr/local/portage/layman/local-overlay" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="7zip X acl acpi alsa avahi berkdb bluetooth branding bzip2 cairo cdaudio cddb cdr cdrom cli cracklib crypt css cups dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox firefox3 fortran gdbm gedit gif glitz gnome gnome-keyring gpm gstreamer gtk hal iconv ipv6 isdnlog jack java jpeg kde laptop ldap libnotify mad matroska midi mikmod mozilla mp3 mpeg mudflap nautilus ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection ruby sdl session spell spl ssl startup-notification svg sysfs tcpd tga thunderbird tiff truetype unicode usb userlocales vorbis wifi win32codecs wireshark wma x86 xcb xml xorg xulrunner xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fglrx ati" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #0) > revdep-rebuild complains about "broken /usr/lib/libAMDXvBA.so.1.0 (requires > libstdc++.so.5)". Resulting in re-emerging ati-drivers but this does not solve > the problem. > I've tried emerging lib-compat but the version of libstdc++ is not the correct > one. > You need to emerge sys-libs/libstdc++-v3 to get rid of that message.
(In reply to comment #1) > (In reply to comment #0) > > revdep-rebuild complains about "broken /usr/lib/libAMDXvBA.so.1.0 (requires > > libstdc++.so.5)". Resulting in re-emerging ati-drivers but this does not solve > > the problem. > > I've tried emerging lib-compat but the version of libstdc++ is not the correct > > one. > > > > You need to emerge sys-libs/libstdc++-v3 to get rid of that message. > Doesn't this suggest that ati-drivers should depend on virtual/libstdc++, like it did prior to 8.471.3? There is no explanation in the changelog as to why it was removed.
Same problem here with ati-drivers-8.561 >Doesn't this suggest that ati-drivers should depend on virtual/libstdc++, like >it did prior to 8.471.3? There is no explanation in the changelog as to why it >was removed. I have the same question, since I had the problem with other versions of ati-drivers, too.
same thing here with x11-drivers/ati-drivers-8.542 Could someone please re-add the dependency on libstdc++-v3? This creates unnecessary maintenance work.
(In reply to comment #4) > same thing here with x11-drivers/ati-drivers-8.542 > Could someone please re-add the dependency on libstdc++-v3? This creates > unnecessary maintenance work. > This bug is the same: #243172
(In reply to comment #5) > > This bug is the same: #243172 > That's correct, this bug should be closed and marked as a duplicate. Let's all go over to #243172 and start jumping up and down there. :)
(In reply to comment #6) > (In reply to comment #5) > > > > This bug is the same: #243172 > > > > That's correct, this bug should be closed and marked as a duplicate. Let's all > go over to #243172 and start jumping up and down there. :) > This is similar to #243172 but not quite. Bug #243172 deals with amd64 and a segfault issue. However they are similar in that running revdep-rebuild keeps complaining about libAMDXvBA.so.1.0 and thus re-emerges the ati-drivers ebuild. So they are definitely related, but are completely two separate issues.
(In reply to comment #7) > > This is similar to #243172 but not quite. Bug #243172 deals with amd64 and a > segfault issue. However they are similar in that running revdep-rebuild keeps > complaining about libAMDXvBA.so.1.0 and thus re-emerges the ati-drivers ebuild. > So they are definitely related, but are completely two separate issues. > Ah yes, I see what you mean. I didn't look closely the first time. :) It seems that their bug is actually solved with the more recent version of the driver, but they are conflating it with the symptoms of this bug, right? Can Jeff Gardner say anything on the issue of this bug, since it appears that the libstdc++ dependency was removed on his watch?
Fixed in 8.573-r1. Thanks!
I'm not pleased with the resolution of this bug. libstdc++-v3 is a horrible package, and I don't particularly want it on my system. It's old and breaks things. In fact, when I was emerging it so I could put in this comment how much space it was wasting on my system for a single .so file I will never use, I ran into bug 220241, so it wastes my time as well as space. :) Can we please have a USE flag for this or something. The choice should be between emerging the libstdc++-v3 dependency or removing the libAMDXvBA.so.1.0 file post-install. mplayer already has an xvmc USE flag. So we can use that. Yay.
Just out of curiosity, Jeffrey, are you sure that it's sys-libs/libstdc++-v3 that it should depend on and not virtual/libstdc++?
(In reply to comment #10) > I'm not pleased with the resolution of this bug. > > libstdc++-v3 is a horrible package, and I don't particularly want it on my > system. It's old and breaks things. What does it break? I don't see any open bug reports about it breaking things. > In fact, when I was emerging it so I could put in this comment how much space > it was wasting on my system for a single .so file I will never use, I ran into > bug 220241, so it wastes my time as well as space. :) But that bug is apparently resolved and I don't see how it relates to libstdc++-v3? And that one single .so file takes up 736kB on my system: is that really such a drama or does it take up more on yours? Sorry to sound so argumentative, I just don't currently see how your arguments are supported, but I would like to hear your explanation. On a related note... Is this reliance on libstdc++ the result of bad coding on the part of ATI, or is it a perfectly reasonable dependency? I.e., should we be asking ATI to fix it in their driver?
(In reply to comment #11) > Just out of curiosity, Jeffrey, are you sure that it's sys-libs/libstdc++-v3 > that it should depend on and not virtual/libstdc++? > I thought of that but I had problems installing the old gcc version and libstdc++-v3-bin. Patching libstdc++-v3 and making that a dep seemed the best way to go. ATI lists it as a dep on their site. When that changes, so will we.
(In reply to comment #12) > What does it break? I don't see any open bug reports about it breaking things. Well, there was a time a couple of years ago when I purged it off my system because various things kept trying to use it instead of libstdc++.so.6 provided by gcc. That might not be the case any more. And you're right, it's not very big. But it does take a long time to emerge. It seems that now there is a virtual which points to the old version of gcc (which will do the same compiling and then some) and a -bin package. The -bin package is the right solution! The only real reason you need libstdc++.so.5 nowadays is to support binary packages that need to rely on a lowest common denominator across various versions of various distributions. It's a case of send a binary to catch a binary. But libstdc++-v3-bin is only currently for ia64 and ppc64. Maybe I should report a bug about that instead. ;)
Oh hey! Good news! In the last couple of days someone made a stealth update (no version bump) to the only available version of libstdc++ and caused no less than three new bugs, one of which I also experienced and hacked my way around in a stupid fashion, only to hit another one previously reported which I have no idea how to fix! bug #259171 , bug #259173 , bug #259192 I hope this satisfactorily answers your question about how totteringly unstable that package is.
(In reply to comment #15) > > I hope this satisfactorily answers your question about how totteringly unstable > that package is. > Regardless, as was pointed out, ATI makes the driver and lists it as a dependency, which is why I suggested that maybe it's ATI we should be harassing to fix their driver. Jeffrey, there may be people out there that are using the old gcc or the libstdc++ binary package (ia64/ppc), so wouldn't it be better to use virtual/libstdc++ so long as it doesn't create any new problems? Unfortunately, there is the problem that virtual/libstdc++ seems to prefer installing the old gcc rather than the compatibility packages, which would be annoying for users that don't already have one of the compatibility packages installed. One simple solution to that last issue is masking the old gcc. Anyway, it's probably unnecessary fuss, but it's a possible solution if some cranky ia64/ppc users come calling.
