Joined: 14 Nov 2012
|Posted: Mon Feb 17, 2014 8:01 pm Post subject: [SOLVED] emerge inteded behavior with abi_x86_32
I recently encountered confusing behavior with emerge and equery tools. It is sort of niche case but never the less it happened to me.
I installed with ABI_X86="64" in my make.conf. Post-install, I realized I needed 32 bit binaries, so I edited make.conf and changed ABI_X86 to "64 32". I then assumed that would update all required lbraries since ABI_X86="32" adds the use flag abi_x86_32 to all packages. So I did emerge -auDN world to upgrade the packages to multi-lib.
After doing this, most 32-bit programs (but not all of them) would segfault. Primarily Second Life viewers and Steam. However, other 32-bit applications would run. I made a simple helloworld.c file and compiled it with -m32 and with default settings and both ran fine. I also ran a small hello world type app in c++ that would create a window, and it worked.
So, it appears some of my libraries have 32-bit multilib enabled and some don't. Meaning that emerge -auDN while changing ABI_X86 doesn't affect all packages.
I did a workaround by copying the results of equery h abi_x86_32, using regular expressions to trim the version numbers, and then saving it as a new set and emerging it.
Curiously, when I went to re-emerge all these packages, emerge only told me the atom for each package and did not specify use flags changed.
I am not sure if they have or not, I am currently compiling. But this behavior is ambiguous and I'm wondering if it is intended to behave in a way where equery h reports that packages have a use flag while emerge -auDN doesn't detect new use flag abi_x86_32 and it won't even list it as a use flag when emerging.
I realize this is sort of a niche use case. I emerge with ABI_X86="64" and later switched. http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=5 The handbook does not call for changing ABI_X86 or anything by default. Is this also intended?
EDIT: it turns out everything was fine with ABI_X86 type things regardless of what I did. I was on the wrong path.
However, I did find out that glibc 2.18 breaks 32-bit applications even if you have multi lib and emul packages all in working order. I resolved the issue by emerging glibc 2.19 from an unofficial overlay. It seems no one in the IRC is aware of this ans I spent several days trying to pin this down.
Is this something to file a bug report over?