In their natural state, x11-libs/gtk+ and x11-libs/pango use information from a config file in /etc (/etc/gtk-2.0/gdk-pixbuf-loaders etc.) to load various plugins at runtime. The path to that config file is compiled-in. Obviously this screws up multilib environments. Therefore, until 2 weeks ago, Gentoo patched gtk+ and pango to use host-specific config paths for config files (/etc/gtk-2.0/i686-pc-linux-gnu/gdk-pixbuf-loaders etc.). So all was well. When compiling under amd64, the patch to fix the config file path was applied automatically. When compiling under x86, the patch was applied only when $CONF_LIBDIR == lib32 (as would be the case when building 32-bit code for a multilib system). On 21 Feb, the 'use x86 && [ "${CONF_LIBDIR}" == "lib32" ]' option was removed because, I quote, > we don't need the use x86 && [[ LIBDIR == lib32 ]] hack anymore This change broke 32-bit gtk apps for anyone who, for example, uses libraries from a 32-bit chroot in their 64-bit desktop. [People use libraries from 32-bit chroots instead of relying on emul-linux-x86-* because emul-linux-x86-* only includes stable versions, but sometimes one needs ~x86 libraries.] There seems to be no reason to remove the host-specific config paths. The one line in the ebuild didn't hurt x86 users, and it greatly helped chrooters. IMHO, the change should be reverted.
On further examination, "use x86 && [[ LIBDIR == lib32 ]]" is an ugly hack that does not deserve to live. Probably the correct solution is to use "has_multilib_profile"; gtk+ already does that, but pango needs to be fixed. Then people with custom chroots etc. can just make themselves a custom x86 multilib profile.
Created attachment 112666 [details] pango-1.14.10.ebuild pango ebuild using has_multilib_profile
(In reply to comment #1) > Then people with custom chroots etc. can just make themselves a custom x86 > multilib profile. See, you don't even have to do that. You can simply use default-linux/amd64/dev/32bit-userland. And it works with the ebuilds as they are. If you want to use the 32bit files from your chroot in your native environment, it should be an emul-chroot. http://amd64.gentoo.org/emul has instructions on how to build one. This is why I removed the hack in the first place. I hope that helped.
