First, I ran emerge -av --depclean; then revdep-rebuild. Several broken packages were fixed and the program ended with an "... All done." As a check, I ran revdep-rebuild again; a broken link was listed and (supposedly) corrected. Everytime I run this rebuild utility, the identical breakage is cited and the utility ends with "All done." The following is the complete terminal output of the utiliity: localhost / # revdep-rebuild Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib32/libGL.so.1.0.9746 (requires libX11.so.6 libXext.so.6) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) Dynamic linking on your system is consistent... All done. localhost / # Reproducible: Always Steps to Reproduce: 1.See terminal line input/output provided in Description. 2. 3. Actual Results: See Description Expected Results: No broken links found! I was logged-in as root, into X with gnome, and into a terminal. I am running AMD64 Gentoo 2.6.20-r8 on a dual Opteron server. No other programs initialized at the time of this error.
What if you emerge app-emulation/emul-linux-x86-xlibs? Does that fix the problem?
This issue is resolved in later versions. You're currently running 9746 which is an ~arch only marked version that is older then the current stable arch versions. It is also completely unsupported by NVIDIA themselves. The version you are currently using has known issues by us and NVIDIA themselves along with security issues. It is scheduled for removal shortly. The suggestion in Commment #1 will fix your issue, but ultimately, you will need to upgrade versions.
I removed 9746 earlier today. The problem still isn't exactly fixed, even in the newer versions, because we have no way to determine if our profile is multilib or not in the *DEPEND section and any determination in the global scope invalidates the cache. All in all, it is an ugly situation.
It was never adequately explained why we couldn't have a multilib USE flag for depends. There are a few apps like this that would need this (i.e. mplayer-bin)
I don't really know, either. The multilib stuff was switched right about when I started running Release Engineering, but I didn't really get very involved in it. I would suspect that the lack of a way to force-enable a USE flag on in a profile had something to do with it, since so many users were doing things like USE=-* or USE=-multilib and breaking their systems. At any rate, I have started a discussion about this on the gentoo-dev list, so we'll see what we can come up with, collectively.
*** Bug 198294 has been marked as a duplicate of this bug. ***
Looks like no one ever answered the e-mail to the -dev ML and we still don't have a solution for this.
I found the same bug in the ati-drivers ebuild. Following discussions on the forums (http://forums.gentoo.org/viewtopic.php?p=4466561), the following code snippet appended after the RDEPENDS section of the ati-drivers.ebuild fixed the problem: <code> if [ ! "${MULTILIB_ABIS/amd64/}" == "${MULTILIB_ABIS}" ] then RDEPEND="${RDEPEND} app-emulation/emul-linux-x86-compat" fi </code>
That code invalidates the metadata cache as it is executed using the profile/environment of the machine performing the metadata run. It is not safe for inclusion in the tree, ever. The only way we currently have to do this sort of thing in the global scope is a USE flag, but the multilib profiles no longer have a specific USE flag, so we're right back to square one. About the only thing that I can think of to "fix" this is to reintroduce the multilib USE flag and force-enable it on multilib-enabled profiles.
(In reply to comment #9) > That code invalidates the metadata cache as it is executed using the > profile/environment of the machine performing the metadata run. It is not safe > for inclusion in the tree, ever. The only way we currently have to do this > sort of thing in the global scope is a USE flag, but the multilib profiles no > longer have a specific USE flag, so we're right back to square one. About the > only thing that I can think of to "fix" this is to reintroduce the multilib USE > flag and force-enable it on multilib-enabled profiles. > This is something I would be happy with.
Adding amd64/ppc64/sparc to get their thoughts on this. This same issue is stopping bug #173962 from being resolved, as it has exactly the same type of issue. The simple "problem" here is that we have no way of using has_multilib_profile (or any other testing) in the global scope without invalidating the cache.
sparc/linux is not a multilib system; we are always 64-bit kernel/32-bit user. And so we don't run into this specific problem if I understand correctly what you are asking: I *think* our only binary package is opera (please don't hold me to that), and I don't believe that we should ever run into a problem like this one. If I am completely missing the point, feel free to enlighten me. :)
No. Your current supported system isn't truly multilib, but sparc is capable of it, which is why I was asking for the sparc team's input, as well as amd64/ppc64, which are more directly involved. I guess my point was to have more eyes on it as a sanity check before I went and proposed it further.
Ah, now understood. If you are asking about reintroducing a multilib USE flag for this situation, that looks about the cleanest solution to me. I ask other sparc people to chime in as well on this. (Full disclosure: I also run amd64, and there I would certainly favor it.)
+1 for USE=multilib and use.force from me, having both an amd64 and ppc64-32ul box.
*** Bug 173962 has been marked as a duplicate of this bug. ***
I'm changing the summary to show this affects both ATI and NVIDIA drivers.
As I wrote in the other bug report, I think this problem doesn't exist anymore. At least find 8.42.3 -name '*.so' -exec ldd "{}" ";" |grep libstdc++ doesn't return any results anymore. It doesn't seem to need emul-linux-x86-compat or libstdc++-3.3. You might want to change the summary to reflect that. (For 8.40.4 it returns several results, for both 64bit and 32bit lib.)
Great glad I just committed ati-drivers 8.42.3 then :) Wasn't sure if I needed to do something to address this. Seems like it just needs to be addressed in older versions. Not really a maintainer of said package atm. So don't think I will be updating the past ones, but might one day.
(In reply to comment #19) > Great glad I just committed ati-drivers 8.42.3 then :) Wasn't sure if I needed > to do something to address this. Seems like it just needs to be addressed in > older versions. Not really a maintainer of said package atm. So don't think I > will be updating the past ones, but might one day. > I knew that these aren't needed since the release of that driver. But I didn't want to introduce too many changes till this driver gets in portage (That bump bug was already confusing enough) and I wanted to double check it. I also guess it is better to have an ebuild with an unneeded dependency than one with an important dependency missing. Should I file an extra bug about this or can this be handled here?
(In reply to comment #18) > As I wrote in the other bug report, I think this problem doesn't exist anymore. > At least > find 8.42.3 -name '*.so' -exec ldd "{}" ";" |grep libstdc++ > doesn't return any results anymore. It doesn't seem to need > emul-linux-x86-compat or libstdc++-3.3. > You might want to change the summary to reflect that. > > (For 8.40.4 it returns several results, for both 64bit and 32bit lib.) > Small correction to myself, the libstdc++-v3 is still needed by amdcccle, but the emul-linux-x86-compat (and that is the one we're talking about) can go, since there is a 32bit and a 64bit version of amdcccle (and on 64bit systems only the last one gets installed).
fixed by 8.433
Whoops, issue not solved.
(In reply to comment #14) > Ah, now understood. If you are asking about reintroducing a multilib USE flag > for this situation, that looks about the cleanest solution to me. I ask other > sparc people to chime in as well on this. (Full disclosure: I also run amd64, > and there I would certainly favor it.) > So, have there been any steps in this direction? (In reply to comment #15) > +1 for USE=multilib and use.force from me, having both an amd64 and ppc64-32ul > box. > Wouldn't it be more like USE=-multilib in use.mask?
(In reply to comment #24) > So, have there been any steps in this direction? Nope. We're a bit busy doing a release at the moment.
I saw, that ati-drivers does now have a new dep: amd64? ( app-emulation/emul-linux-x86-xlibs ) When this bug actually gets fixed I guess, that the check should be added there as well.
(In reply to comment #26) > I saw, that ati-drivers does now have a new dep: > amd64? ( app-emulation/emul-linux-x86-xlibs ) > > When this bug actually gets fixed I guess, that the check should be added there > as well. > That dep is very bad to have. Since not all amd64 arch profiles are multilib. That package would be blocked on non-multilib profiles as well as 32 bit userland profiles. This would result in a total cascading blocker for anything that used X, and it would be completely unresolvable on the user's side.
(In reply to comment #27) > (In reply to comment #26) > > I saw, that ati-drivers does now have a new dep: > > amd64? ( app-emulation/emul-linux-x86-xlibs ) > > > > When this bug actually gets fixed I guess, that the check should be added there > > as well. > > > > That dep is very bad to have. Since not all amd64 arch profiles are multilib. > That package would be blocked on non-multilib profiles as well as 32 bit > userland profiles. This would result in a total cascading blocker for anything > that used X, and it would be completely unresolvable on the user's side. > As I said, that is what portage actually does, I was quite surprised because the other dependency (to -compat) has just been removed (and that had multilib? in it). If that would have such a big impact (I don't know how many users use no-multilib profiles), maybe it should be changed rather sooner than later.
(In reply to comment #27) > > That dep is very bad to have. Since not all amd64 arch profiles are multilib. > That package would be blocked on non-multilib profiles as well as 32 bit > userland profiles. This would result in a total cascading blocker for anything > that used X, and it would be completely unresolvable on the user's side. > like me ;) ...is it going to be changed? Or must i change to a multilib profile only for this driver. I opened a bugreport https://bugs.gentoo.org/show_bug.cgi?id=201253 before reading this.... sorry, maybe it should be masked as a duplicate. Mfg, unregistr3d
(In reply to comment #27) > (In reply to comment #26) > > I saw, that ati-drivers does now have a new dep: > > amd64? ( app-emulation/emul-linux-x86-xlibs ) > > > > When this bug actually gets fixed I guess, that the check should be added there > > as well. > > > > That dep is very bad to have. Since not all amd64 arch profiles are multilib. > That package would be blocked on non-multilib profiles as well as 32 bit > userland profiles. This would result in a total cascading blocker for anything > that used X, and it would be completely unresolvable on the user's side. > As ati does not support anything other then multilib setups on x86_64 there is no need to make it avaliable for non-multilib profiles. As for the 32bit userland issue I will be more then happy to look at it once I have had a chance to review the profile, which last I knew was still expieremental.
*** Bug 209392 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > +1 for USE=multilib and use.force from me What's up with this?
Sparc uses neither the ati-drivers/nvidia-drivers nor app-emulation/emul-linux-x86-xlibs --- removing from the CC.
*** Bug 210204 has been marked as a duplicate of this bug. ***
ppc64, as far as I know, does not use either of these. Removing from cc, please re-add should I be wrong.
*** Bug 212088 has been marked as a duplicate of this bug. ***
This is FIXED with the 2008.0 profiles, but not previous profiles, which should be deprecated due to not providing a global-scope-capable detection of multilib.
Set a whiteboard status so it's easy to see what the result is. Marking this as fixed since we've got it in 2008.0 and newer.
