On Fri, 09 Aug 2013 19:23:50 +0200 Thomas Sachau <to...@gentoo.org> wrote:
> Alexis Ballier schrieb: > > On Fri, 09 Aug 2013 18:32:04 +0200 > > Thomas Sachau <to...@gentoo.org> wrote: > > > >> Alexis Ballier schrieb: > >>> On Fri, 09 Aug 2013 17:32:56 +0200 > >>> Thomas Sachau <to...@gentoo.org> wrote: > >>> > >>>> As the topic says, when someone converts an ebuild to multilib, > >>>> please dont disable binary building for other ABIs, as has > >>>> already been done for some packages. > >>>> > >>>> This will break e.g. for users who target 64bit toolchain and > >>>> 32bit userland, since those would not get any binaries from > >>>> building for none-default ABIs. > >>>> > >>> > >>> - submit a patch against multilib_is_native_abi for those corner > >>> cases > >> > >> huh? Please tell me, how a changed multilib_is_native_abi function > >> would help here. Either you restrict something to native abi or you > >> dont, having a check telling you "true - we are either native abi > >> or not" is not really usefull, is it? > >> > > > > native abi = the abi you want the binaries for and the one you > > always build your libs with... > > so tell me the native abi for this case: toolchain=64bit, > userland=32bit > > from your line: the abi you wan the binaries for: x86 > the one you always build your libs with: amd64 > > native abi = x86 = amd64? First of all, toolchain is part of userland For this case maybe the DEFAULT_ABI variable is a bit abused atm. This can be solved by adding NATIVE_ABI=$DEFAULT_ABI to the profiles and changing multilib_is_native_abi to ABI == NATIVE_ABI.
