This revision breaks multilib-portage builds. (So please make it block bug 306835) A bit of history: Non-multilib archs sometimes don't have have ARCH set so that is the wrong bell to ring. Fortunately, there's a solution. Non-multilib archs may not set ABI. But DEFAULT_ABI is always set. If ABI is set, that is the one to use, if you'd like to enable multilib-portage to do profane things behind your back with the code that you have so lovingly crafted. So if you could run: sed -e 's/DEFAULT_ABI/ABI:-DEFAULT_ABI/' -i $EBUILD On the ebuild, we will use ABI if it's set, DEFAULT_ABI otherwise, which is The Right Thing To Do. Peace on earth will return and the divine and the profane will achieve balance ^_^
Whoops, screwed the pooch when I cloned bug 471079, since all you people got to be on the CC list. AFAICT, this should be assigned to x11 and fuzzyray and maksbotan should be CC'ed.
It would probably work. Not sure if we are really supposed to develop a tree-wide hack to support a hacked variant of portage. It'd be better if multilib-portage just set DEFAULT_ABI since they're doing a global kind of mess anyway.
(In reply to Michał Górny from comment #2) > It would probably work. Not sure if we are really supposed to develop a > tree-wide hack to support a hacked variant of portage. It'd be better if > multilib-portage just set DEFAULT_ABI since they're doing a global kind of > mess anyway. They *are* setting DEFAULT_ABI, but when the phase is run for ABI!=DEFAULT_ABI, the dir for DEFAULT_ABI doesn't exist, so *boom* the build fails. The problem only arises when normal ebuilds try to do multilib and don't know the conventions of the ABI and DEFAULT_ABI in multilib builds. I guess that kind of leaves the smelly thing sitting at multilib-portage's doorstep, because "it works for me" but the change is trivial and also helps ensure correctness if you're crosscompiling, so I don't see why not.
*** This bug has been marked as a duplicate of bug 473362 ***
