Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles

[Thomas Sachau]

Matt Turner schrieb:
> On Sun, Jul 1, 2012 at 7:29 AM, Thomas Sachau <tommy@g.o> wrote:
>> Matt Turner schrieb:
>>> On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau <tommy@g.o> wrote:
>>>>
>>>
>>> I'm interested in this because I'm regularly annoyed with the emul-
>>> packages and also because multilib is pretty important for mips.
>>>
>>>> If a package has dependencies, then those dependencies are required to have
>>>> at least the same targets enabled as the package
>>>
>>> That seems like the obvious (but perhaps naive) choice. What about
>>> depending on packages that don't install libraries, like x11-proto/
>>> packages or generators like dev-util/indent?
>>>
>>> Maybe I just don't understand. Would these packages even have ABI flags?
>>
>> All packages do get the ABI flags (with the needed EAPI or via enabled
>> portage feature, which is currently in the multilib branch).
>>
>> If a package does not install anything ABI-specific (no headers, no libs
>> and no binaries), then there is no overhead, since it will just get
>> compiled/installed for one ABI, even if multiple ABI flags are enabled.
>
> I suppose that's just for ease of implementation? Not having to
> special-case packages that don't install binaries.

I dont follow. Did you think about only having additional ABI flags for
certain cases?

>>> For mips, we'd like to have gcc built as an n64 binary, which would
>>> require its run-time dependencies (mpfr, mpc, gmp, etc.) to be
>>> available as n64 as well, but the rest of the system to be n32
>>> binaries. Does this fit with your understanding (and proposed
>>> solution) of the problem?
>>
>> I guess, you require additional n64 libs for gcc dependencies like mpfr,
>> mpc and others, while your default ABI will be n32.
>>
>> This should work fine with my proposal, you just have the (already
>> default enabled) n32 ABI flag enabled, which results in everything being
>> built just for n32. For the packages, where you require additional n64
>> libs, you just enable the n64 ABI flag in addition. And if you need n64
>> binaries too, you enable the abiwrapper USE flag for them.
>
> One follow-on question. Consider having a package dev-libs/libpkg
> already installed for ABI="n32 -n64" and wanting to emerge another
> package that depends on it with ABI="-n32 n64". Will dev-libs/libpkg
> have to be rebuilt twice (once for the existing n32 ABI and again for
> the newly needed n64), or can we optimize this case by recognizing
> that building for multiple ABIs means entirely separate builds?

Those ABI flags behave the same as other USE flags: When you change
them, you have to recompile the package including all the content, that
has been compiled previously.
If you want the compile for each ABI seperate, then you would have to
handle them more like SLOTS, but with a new syntax, with a collision
handler for the common content and how to handle that in the user UI. I
fear, that this would be way more complicated to implement in a sane
way, so i dont plan to go that route.


-- 

Thomas Sachau
Gentoo Linux Developer