Summary: | x11-proto/xcb-proto-1.8-r3 - Fails in compile phase for multilib-portage | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | crabbed halo ablution <crabbedhaloablution> |
Component: | [OLD] Library | Assignee: | Maxim Koltsov (RETIRED) <maksbotan> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | ed, multilib+disabled, x11 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
crabbed halo ablution
2013-05-29 00:29:51 UTC
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 *** |