GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 02:52 PM, Zac Medico wrote:
> On 07/01/2012 02:39 PM, Matt Turner wrote:
>> On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau <tommy@gentoo.org> wrote:
>>> Matt Turner schrieb:
>>>> 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?
>>
>> Right. It seems to me that not having the ABI flags for packages like
>> x11-proto/* would make more sense, but may be more work to implement.
>
> It seems like this could easily be controlled by setting a PROPERTIES or
> RESTRICT value in the ebuild. Also, it might be useful to give the
> ebuild similar control over the abiwrapper flag via PROPERTIES or RESTRICT.
On irc, I asked Tommy about the abiwrapper thing, and he suggested to
set IUSE="+abiwrapper" for packages containing programs like qmake which
are known to produce ABI specific output.
--
Thanks,
Zac
07-01-2012, 10:30 PM
Zac Medico
GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 02:34 PM, Thomas Sachau wrote:
> Zac Medico schrieb:
>> On 07/01/2012 04:29 AM, Thomas Sachau wrote:
>>> Matt Turner schrieb:
>>>> On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau <tommy@gentoo.org> 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.
>>
>> For a package like this that does not install anything ABI-specific,
>> does the package manager still execute phases for each enabled ABI, or
>> is there some way for the ebuild to indicate whether or not its phases
>> need to be executed for each enabled ABI?
>>
>
>
> This is dynamicly checked at runtime, no need to modify the ebuilds and
> also no needless compilation, when there is no ABI-specific content.
>
> A more detailed answer at package manager level:
> After the src_install phase for the first requested ABI has been
> finished, the content of $DESTDIR is checked. If there is no ABI
> specific content, the other enabled ABIs are skipped and the following
> steps are done as usual.
In case anyone want some more detail, here's a follow-up question from irc:
<zmedico> Tommy[D]: does any ELF executable qualify as "abi specific"
and trigger builds for all ABIs?
<Tommy[D]> zmedico: if it goes into any of /bin /usr/bin /sbin /usr/sbin
and you enable the abiwrapper USE flag, yes, otherwise you just request
a binary for the default ABI, so no need to rebuild everything for no need
--
Thanks,
Zac
07-02-2012, 12:45 AM
Jonathan Callen
GLEP draf for cross-compile support in multilib profiles
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 07/01/2012 05:39 PM, Matt Turner wrote:
> On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau <tommy@gentoo.org>
> wrote:
>> Matt Turner schrieb:
>>> 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?
>
> Right. It seems to me that not having the ABI flags for packages
> like x11-proto/* would make more sense, but may be more work to
> implement.
>
For x11-proto/* you currently do need to build the package for each
individual ABI because they install a file in
/usr/$(get_libdir)/pkgconfig. This should probably be changed
upstream to install to /usr/share/pkgconfig, as there is nothing
ABI-specific in there.
- --
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> On 07/01/2012 02:34 PM, Thomas Sachau wrote:
> > Zac Medico schrieb:
> >> On 07/01/2012 04:29 AM, Thomas Sachau wrote:
> >>> Matt Turner schrieb:
> >>>> On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau
> >>>> <tommy@gentoo.org> 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.
> >>
> >> For a package like this that does not install anything
> >> ABI-specific, does the package manager still execute phases for
> >> each enabled ABI, or is there some way for the ebuild to indicate
> >> whether or not its phases need to be executed for each enabled ABI?
> >>
> >
> >
> > This is dynamicly checked at runtime, no need to modify the ebuilds
> > and also no needless compilation, when there is no ABI-specific
> > content.
> >
> > A more detailed answer at package manager level:
> > After the src_install phase for the first requested ABI has been
> > finished, the content of $DESTDIR is checked. If there is no ABI
> > specific content, the other enabled ABIs are skipped and the
> > following steps are done as usual.
>
> In case anyone want some more detail, here's a follow-up question
> from irc:
>
> <zmedico> Tommy[D]: does any ELF executable qualify as "abi specific"
> and trigger builds for all ABIs?
> <Tommy[D]> zmedico: if it goes into any
> of /bin /usr/bin /sbin /usr/sbin and you enable the abiwrapper USE
> flag, yes, otherwise you just request a binary for the default ABI,
> so no need to rebuild everything for no need
How about executables which go into /lib or /libXX?
--
Best regards,
Michał Górny
07-02-2012, 05:06 PM
Thomas Sachau
GLEP draf for cross-compile support in multilib profiles
Matt Turner schrieb:
> On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau <tommy@gentoo.org> wrote:
>> Matt Turner schrieb:
>>> 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?
>
> Right. It seems to me that not having the ABI flags for packages like
> x11-proto/* would make more sense, but may be more work to implement.
The problem here is the following: How do you know before the
src_install phase, that a package has no ABI-specific content? And even,
if you know that, how would you define the dependency part? This would
probably become pretty complex, since it also has to support corner cases.
>
>> 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.
>
> Ouch. I already think a mechanism for telling the package manager "you
> don't need to rebuild this entire package to turn on /this/ USE flag"
> is needed. For ABIs, the situation seems much more clear-cut. In fact,
> it seems rather important.
This would require a good amount of changes. Since my work with
multilib-portage started in 2009 and is still not in the PMS, also i
tried to keep it simple, i would not even try to guess an ETA for both
of your, in my eyes more complex, ideas. ;-)
I of course wont prevent you from preparing them and getting them in,
they may be nice, especially removing the need to recompile already
compiled code. Just dont underestimate the work with it.
--
Thomas Sachau
Gentoo Linux Developer
07-02-2012, 05:08 PM
Ciaran McCreesh
GLEP draf for cross-compile support in multilib profiles
On Mon, 02 Jul 2012 19:06:43 +0200
Thomas Sachau <tommy@gentoo.org> wrote:
> The problem here is the following: How do you know before the
> src_install phase, that a package has no ABI-specific content?
You make every package that has ABI specific content explicitly say so,
as metadata.
--
Ciaran McCreesh
07-04-2012, 02:02 PM
Luca Barbato
GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 01:41 PM, Thomas Sachau wrote:
> I guess, you are mixing cross-compile support in multilib profiles and
> cross-compile support with cross-toolchains, multilib-portage is for the
> first one, while crossdev is for the second one.
>
> My suggestion does not support e.g. compiling for ppc with an amd64
> profile, on amd64 it only can support x86 and x32. Since all of these
> binaries can run with an amd64 kernel and you build for at least one
> target, you always have a binary around, no need for an extra HOST
> dependency.
You can run an arm binary on amd64 (through binfmt+qemu-user static)
> I dont know, what exactly you mean with "play properly with ld" and
> "cross-vs-host paths", so cannot respond to those.
multilib works because the runtime linker picked is the right one for
each ABI, thanks to qemu makes no difference if that ABI is native or not.
cross vs host paths is an annoying problem due the slightly different
behaviour between native and cross compiler toolchains, it tends to
ignore environment variables and other small differences making dropping
an native cross compiler in a qemu chroot, QUITE a creative activity.
GLEP draf for cross-compile support in multilib profiles
