There are several binary x86 packages in portage that install 32bit plugins in /usr/lib64/nsbrowser/plugins. I think it would make a lot more sence to install these plugins in /usr/lib32/nsbrowser/plugins so as not to confuse the webbrowswer. Also at present both mozilla-firefox and mozilla-firefox-bin create /usr/lib64/nsbrowser/plugins/libnullplugin.so (one 32bit and one 64bit). This issue is actually quite easy to fix as the nslugins eclass seems to make use of get_libdir correctly. I made the following addition to mozilla-firefox-bin ebuild: pkg_setup() { if use amd64; then ABI="x86" fi } forcing get_libdir to resolve as lib32 (as it should for a 32bit package) and now libnullplugin is installed to /usr/lib32/nsbrowser/plugins (as it should). Also /opt/firefox/plugins -> /usr/lib32/nsbrowser/plugins (as it should). Exactly the same change can be made to the following packages to get the 32bit plugins installed in lib32: app-text/acroread media-video/realplayer net-www/netscape-flash Reproducible: Always Steps to Reproduce: 1. 2. 3.
*** Bug 85823 has been marked as a duplicate of this bug. ***
I will use the following lines instead of your proposal, Herbie: has_multilib_profile && ABI="x86" This will be used in global scope of the ebuild. app-text/acroread-{5.10,7.0} fixed.
net-www/netscape-flash-* fixed. media-video/realplayer-10.0.3 fixed. www-client/mozilla-firefox-bin-* fixed. Resolving as FIXED.
Kugelfang: please apply same fix to www-client/mozilla-bin so that it can locate the 32bit plugins.
done.
