For ati-drivers-8.35.5 under AMD64 there should be a dependency for app-emulation/emul-linux-x86-compat because amdcccle will not start reporting an error about missing libstdc++.so.5. This also can also cause revdep-rebuild to reemerge ati-drivers over over again (Did happen for me.). Reproducible: Always Steps to Reproduce: 1. Install ati-drivers on AMD64 with useflag qt3 2. Make sure emul-linux-x86-compat is not installed or move /usr/lib32/libstdc++.so.5 which is provided by that package 3. Run amdcccle Actual Results: amdcccle: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory Expected Results: Well, load. ;)
*** Bug 174570 has been marked as a duplicate of this bug. ***
Created attachment 116378 [details, diff] patched ebuild Since everyone else seems too busy (*coughs*), here's the needed patch for the ebuild ;>
Thanks, the ebuild now checks for this (in 8.37.6-r1 and up).
Sorry, the last comment made no sense (went to the wrong bug). 8.37.6-r1 now has this dependency. I did not drop the virtual/libstdc++ dependency because it is still needed by the 64 bit libGL.so. Please file a new bug if you believe this is incorrect.
This ebuild requires the multilib use flag is that correct? There are other packages that depend on 32 bit binaries without using this use flag.
I'm also a little bit curious about the way this is fixed. On my system the multilib use flag isn't activated, although it works very well as a multilib system and the profile doesn't point to a no-multilib profile (just to the normal desktop profile). The result is, that the dependency still doesn't get pulled in.
*** Bug 187011 has been marked as a duplicate of this bug. ***
Reopen, the multilib thing needs to die.
According to /usr/portage/profiles/default-linux/use.mask, the whole multilib thing is: # Only used by mips and old amd64 profiles But there are no supported profiles anymore, which have a "-multilib" in any use.mask. Isn't it time for the multilib USE flag, to leave? cu Dieter
The next release seems to contain a 64bit Version of the amdcccle, so maybe the dependency for app-emulation/emul-linux-x86-compat isn't needed anymore. file amdcccle amdcccle: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.4.3, dynamically linked (uses shared libs), not stripped
Looked into it, and it is still needed, by 32bit version of fglrx_dri.so: ldd fglrx_dri.so [...] libstdc++.so.5 => /usr/lib32/libstdc++.so.5 (0xf7509000) [...] Why not just use amd64? ( app-emulation/emul-linux-x86-compat ) instead of amd64? ( multilib? ( app-emulation/emul-linux-x86-compat ) ) The second one doesn't really make sense (or am I wrong on this?), since the library gets installed anyway, so on -multilib systems I've got a library with a missing dependency?
*** Bug 191540 has been marked as a duplicate of this bug. ***
I had this problem with ati-drivers-8.39.4 installing app-emulation/emul-linux-x86-compat resolved the problem for me. The strange think is new system worked for awhile then amdcccle quit. Kept installing virtual/libstdc++ . Maybe linked to expat upgrade? Lets not go there
I found something similar in the nvidia-drivers ebuild: multilib? ( app-emulation/emul-linux-x86-xlibs ) Does this work for nvidia users? I think, that bug 187683 tells about this.
Well, the problem here (both ati and nvidia) is that we don't have an easy way to determine whether something is a multilib profile or not that is usable properly in a global scope. Pretty much anything we would do would invalidate the cache and cause all kinds of nasty problems. While it is easy enough to have the ebuild decide whether or not to install certain files via a has_multilib_profile check, that can't really be used in the global scope due to cache generation issues. We used to use the multilib USE flag, but that has been deprecated for a really long time now. What we really need is to figure out some way to say "I need to depend on this, but only if I am running a multilib profile"...
(In reply to comment #15) > What we really need is to figure out some way to say "I need to depend on this, > but only if I am running a multilib profile"... > Wouldn't it be possible to check the profile link itself and check if it has something like "no-multilib" in it? Like /etc/make.profile -> ../usr/portage/profiles/default-linux/amd64/2007.0/desktop vs. /etc/make.profile -> ../usr/portage/profiles/default-linux/amd64/2007.0/no-multilib/ Maybe the multilib eclass could make use of this and provide something to check.
Anything that checks the profile in use on the local machine in the global scope will potentially invalidate the cache, which is very bad. The problem here is the check has to be something that is valid within the scope of *DEPEND, which is currently limited to USE (oversimplification, but you get the point)... Were we able to do that sort of checking, it would be very simple: has_multilib_profile && RDEPEND="${RDEPEND} app-emulation/emul-linux-x86-compat" The problem is that running such a thing in the global scope would cause an invalid cache, depending on whether the cache generation was run on a multilib-enabled amd64 box or not. Honestly, I'm surprised this has been around for so long without anyone noticing, but it is likely that the people this would affect the most had some other package installed that pulled in the necessary dependencies for itself.
As far I can see, this dependency is no longer needed for ati-drivers 8.40.4. That's because the only file that needs 64 bit emulation is ``amdcccle``, this Catalyst Control Center, which was shipped in a 32 bit version. But according to <http://planet64bit.de/node/2616> and the official ATI Release Notes <https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.40.4.html> the ``amdcccle`` file should now be a 64 bit binary. So, in short: the dependancy can be dropped in the ati-drivers >= 8.40.4 as it is outdated.
(In reply to comment #18) > As far I can see, this dependency is no longer needed for ati-drivers 8.40.4. > That's because the only file that needs 64 bit emulation is ``amdcccle``, this > Catalyst Control Center, which was shipped in a 32 bit version. But according > to <http://planet64bit.de/node/2616> and the official ATI Release Notes > <https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.40.4.html> > the ``amdcccle`` file should now be a 64 bit binary. > > So, in short: the dependancy can be dropped in the ati-drivers >= 8.40.4 as it > is outdated. > No, see comment #11.
Is the 32 bit version of ``fglrx_dri.so`` needed at all? I am running a system without the emulation libraries and haven't found any problems related to this. I just tried a 32-bit Opera, that seems to have problems with x86 emulation libraries missing. Maybe that would be a candidate for something like emul-linux-x86-fglrx?
(In reply to comment #20) > Is the 32 bit version of ``fglrx_dri.so`` needed at all? I am running a system > without the emulation libraries and haven't found any problems related to this. > I just tried a 32-bit Opera, that seems to have problems with x86 emulation > libraries missing. > > Maybe that would be a candidate for something like emul-linux-x86-fglrx? > I guess it is needed, if you run a 32bit application, that makes use of opengl, like wine+a windows game for example. Nevertheless, I think, that if one doesn't use a multilib system these files shouldn't be installed. So the check (that currently seems to be broken) should be taken by the install routine as well (when it is working some day). You are right in one point, if you haven't any emul-x86 libs installed, the file isn't needed.
With ati-drivers-8.42.3 all dependencies on /usr/lib32/libstdc++.so.5 are gone, so it should be save to remove the emul-linux-x86-compat dependency. If 8.42.3 hits the tree, this bug can be marked as resolved since the original problem shouldn't exist anymore. Or the summary should be changed to fit a more general purpose (since this problem doesn't seem to be ati-drivers-specific.).
is there anything wrong on here?
Yes, there is something definitely wrong. This bug is essentially the same as bug #187683 as they're both having the same issue. We need some way to allow the app-emulation/emul-linux-x86-compat dependency to be pulled in when on a multilib system, and not pulled in on non-multilib, and we need it in something that is valid *DEPEND syntax. Currently, that means a USE flag, which is why I called for discussion (on bug #187683) about the reintroduction of the flag now that we can force-enable USE flags on certain profiles. Of course, I'd take any other solution which gets the job done, too.
*** This bug has been marked as a duplicate of bug 187683 ***
