FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-01-2012, 02:55 AM
Luca Barbato
 
Default GLEP draf for cross-compile support in multilib profiles

On 06/29/2012 04:30 PM, Thomas Sachau wrote:

It is interesting, still you need a way to define HOST dependencies
(stuff you need that has to be built on the host since you run it, e.g.
xcb python code generator), something to play properly with ld and
cross-vs-host paths for compilers (that part is _really_ annoying for
qemu-chroots)

lu

--

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
 
Old 07-01-2012, 11:29 AM
Thomas Sachau
 
Default GLEP draf for cross-compile support in multilib profiles

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.

>
> It's clear to me that libraries would be installed in different lib*
> directories dependent on their ABI, but how would typical executables
> be handled?

By default, only the binaries for the first enabled ABI are preserved
(which usually is the default ABI). If you enable the abiwrapper USE
flag, the binaries for all target ABIs are preserved, installed in the
form of $binary-$ABI and $binary will be a symlink to a wrapper, which
calls the right binary for the currently selected ABI.

>
> 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.


--

Thomas Sachau
Gentoo Linux Developer
 
Old 07-01-2012, 11:41 AM
Thomas Sachau
 
Default GLEP draf for cross-compile support in multilib profiles

Luca Barbato schrieb:
> On 06/29/2012 04:30 PM, Thomas Sachau wrote:
>
> It is interesting, still you need a way to define HOST dependencies
> (stuff you need that has to be built on the host since you run it, e.g.
> xcb python code generator), something to play properly with ld and
> cross-vs-host paths for compilers (that part is _really_ annoying for
> qemu-chroots)
>
> lu
>

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.
I dont know, what exactly you mean with "play properly with ld" and
"cross-vs-host paths", so cannot respond to those.

--

Thomas Sachau
Gentoo Linux Developer
 
Old 07-01-2012, 07:27 PM
Matt Turner
 
Default GLEP draf for cross-compile support in multilib profiles

On Sun, Jul 1, 2012 at 7:29 AM, Thomas Sachau <tommy@gentoo.org> 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.

I suppose that's just for ease of implementation? Not having to
special-case packages that don't install binaries.

That seem /okay/ to me, but I'm not writing the implementation so I
only have so much weight. I would be interested to hear what Ciaran,
Brian, and Zac think though.

>> It's clear to me that libraries would be installed in different lib*
>> directories dependent on their ABI, but how would typical executables
>> be handled?
>
> By default, only the binaries for the first enabled ABI are preserved
> (which usually is the default ABI). If you enable the abiwrapper USE
> flag, the binaries for all target ABIs are preserved, installed in the
> form of $binary-$ABI and $binary will be a symlink to a wrapper, which
> calls the right binary for the currently selected ABI.

Ahh, I see. That sounds reasonable.

>> 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?

Thanks,
Matt
 
Old 07-01-2012, 08:52 PM
Thomas Sachau
 
Default GLEP draf for cross-compile support in multilib profiles

Matt Turner schrieb:
> On Sun, Jul 1, 2012 at 7:29 AM, Thomas Sachau <tommy@gentoo.org> 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.
>
> 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
 
Old 07-01-2012, 09:12 PM
Zac Medico
 
Default GLEP draf for cross-compile support in multilib profiles

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?
--
Thanks,
Zac
 
Old 07-01-2012, 09:34 PM
Thomas Sachau
 
Default GLEP draf for cross-compile support in multilib profiles

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.

--

Thomas Sachau
Gentoo Linux Developer
 
Old 07-01-2012, 09:39 PM
Matt Turner
 
Default GLEP draf for cross-compile support in multilib profiles

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.

> 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.
 
Old 07-01-2012, 09:52 PM
Zac Medico
 
Default GLEP draf for cross-compile support in multilib profiles

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.
--
Thanks,
Zac
 
Old 07-01-2012, 09:56 PM
Zac Medico
 
Default 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.

I think it would be helpful to include a short explanation of these
kinds of details in the GLEP, in order to help people wrap their heads
around the whole thing (possibly avoiding the "Huh?" kind of reaction
that you got from Brian).
--
Thanks,
Zac
 

Thread Tools




All times are GMT. The time now is 01:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org