Today, the abi_x86_x32 USE flag was unmasked in profiles/arch/amd64/use.mask (and the unmask in the x32 subprofile removed). This cannot work, because x32 is not enabled in MULTILIB_ABIS for the amd64 multilib profiles (and presumably shouldn't be).
(In reply to Ulrich Müller from comment #0) i'm not following ... why can't it work ? add x32 to your MULTILIB_ABIS and it works just fine. the value of MULTILIB_ABIS should not dictate the masking of ABI vars.
It is inconsistent in profiles. If users have to add x32 to their MULTILIB_ABIS manually, then they can unmask the abi_x86_x32 flag as well.
I've reverted the changes on behalf of multilib@ since they do more bad than good. MULTILIB_ABIS is intended to be static and set by profiles. Its immutability is required for ABI_X86 dependencies to work properly. If users can play with MULTILIB_ABIS, we may as well drop all dependencies and assume people are supposed to manually know what to rebuild and when. Next time, please consult either multilib@ or gentoo-dev@ before doing major changes into multilib in Gentoo. Or at least bother mailing us that you committed something. It's better to know first hand what happened, rather than seeking CVS logs after bug reports and complaints from users. Thanks.
i doubt users are hitting this and reporting things. they'd have to be experimenting with x32 in the first place. having both MULTILIB_ABIS and ABI_X86 makes no sense. the former is redundant when the latter is in effect. arch/amd64/ is the core amd64 logic and not for specific multilib settings. subprofiles are for that, hence unmasking everything in there makes sense.
(In reply to SpanKY from comment #4) > having both MULTILIB_ABIS and ABI_X86 makes no sense. the former is > redundant when the latter is in effect. So far, the system ABIs (glibc in particular) were controlled by choosing a specific profile, like x86, amd64, amd64/no-multilib, or amd64/x32, which defines a suitable MULTILIB_ABIS variable. I see it as an internal profile variable _not_ to be changed by users, and our documentation seems to agree since it doesn't mention it at all. > arch/amd64/ is the core amd64 logic and not for specific multilib settings. > subprofiles are for that, hence unmasking everything in there makes sense. It leads to inconsistencies, e.g. USE dependencies are broken with USE=abi_x86_x32 but x32 not in MULTILIB_ABIS. You cannot set the USE flag without adjusting the variable too, otherwise the flag will have no effect. (What happens is that multilib_get_enabled_abis() in multilib-build.eclass tests the abi_x86_* flags but also calls get_all_abis() from multilib.eclass, which in turn will check the MULTILIB_ABIS variable.) We can investigate if there is some way to get rid of the (older) MULTILIB_ABIS variable while keeping the (newer) ABI_X86 USE_EXPAND. (Maybe package.use.force could be used instead for controlling e.g. glibc's ABIs?) This would require a complete rewrite of multilib.eclass, though.
(In reply to Ulrich Müller from comment #5) i'm aware of the history/code. that doesn't mean it needs to stay that way. MULTILIB_ABIS made sense when there was nothing else, but the multilib build eclasses have no need of it when the relevant ABI_XXX are set. there's no need to completely rewrite multilib.eclass. transitioning to a dynamic value would not be hard. if anything, the current multilib-* eclasses means much of multilib.eclass can simply be deleted.
(In reply to SpanKY from comment #4) > i doubt users are hitting this and reporting things. they'd have to be > experimenting with x32 in the first place. In Gentoo? If people notice that x32 was unmasked, enable it and see that x32 didn't install, they report a bug for the specific package. (In reply to Ulrich Müller from comment #5) > We can investigate if there is some way to get rid of the (older) > MULTILIB_ABIS variable while keeping the (newer) ABI_X86 USE_EXPAND. (Maybe > package.use.force could be used instead for controlling e.g. glibc's ABIs?) > This would require a complete rewrite of multilib.eclass, though. I'd rather say of toolchain*.eclass.
No new comments, restoring the FIXED state.
