Brian Harring schrieb:
> You need a glep here frankly; per the norm, if you want things to move
> faster, then put in time- aka, generate a patch against PMS, write a
> patch for portage, etc, you get the idea. The bit re: a PMS patch is
> mostly that in looking at your proposal... well, I personally don't
> want to write that patch (nor do I suspect ulm/ciaran do either).
As written earlier, a patch for portage exists already (just the diff
between multilib and master branch of portage).
Now, in addition, a GLEP draft for cross-compile support in
> One thing to note; this has been posted for all of 2-3 days; that's
> not exactly much time for 1) people to comment, 2) people to frankly
> comprehend the quite dense description you wrote.
This may be true, but as you may have seen afterwards, beside the
responses to my mail about planned council asking, there have not been
any further responses, so the relatively short time since my mail doesnt
seem like the reason for missing responses.
> Please write a glep covering details of the implementation,
> background, preferablly why this route over others. Bluntly... clue
> everyone else in rather than hoping they'll just sign off on a fairly
> opaque list of things.
It'll be useful for dev education also-
> which is a bit of a requirement for stuff of this sort considering
> it's not going to be a magic deploy/shit works everywhere situation I
See attached GLEP draft.
> Would also be useful getting commentary from crossdev folk considering
> your solution is intended to be (best I can tell) full cross
> compilation support, and they've been leading that front for many,
> many years.
There is an important difference between my cross-compile support for
multilib profiles and crossdev: My suggestion works with the default
toolchain, which itself is able to cross-compile for other targets (like
the amd64/multilib gcc is able to create 32bit libs), while crossdev is
using a different toolchain for the targets.
Of course, if someone from crossdev maintainers wants to comment, he is
free to do so.
Gentoo Linux Developer
Title: Crosscompile support for multilib profiles
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/07/19 12:09:20 $
Author: Thomas Sachau <email@example.com>
Type: Standards Track
Created: 24 Jun 2012
Currently, multilib profiles like amd64 do support other targets, but there
is no simple way to build packages for those seperate targets. A workaround
for this issue are emul packages, which contain precompiled 32bit libs.
This GLEP extends the package manager to allow the user to build packages
from source for targets supported by the profile and toolchain.
There is no way to build packages for other then the default target also
the profile and toolchain do support them. For amd64, there are precompiled
emul packages, which only support a predefined subset of packages, are not
compiled with the respect for the user USE or comiler flags and tend to
become outdated due to the amount of packages they include.
This GLEP will extend the functionality of package managers with a future
EAPI. With this EAPI, users will be able to select additional or different
targets per package by adjusting the additional USE flags. Ebuilds
themselves dont have to be modified to support this. If a dependency does
support the future EAPI, depending packages may require a specific target
to be enabled via use dependencies.
package dev-libs/a uses the future EAPI
packge app-misc/b requires 32bit libs from dev-libs/a
It can now define this in the dependency section as following:
The proposal does add USE flags for each supported target ABI. This allows
the user to select per package, if he wants to compile it for the default
target, additionally for another target or just for another target.
An alternative would have been a global variable defining this support for
all packages at once. This was not done, because it would force the user
to either build all (even unneeded packages) or nothing with additional or
different target support without the ability to choose on a per package level.
The proposel does add a USE flag called "abiwrapper" to control the
behaviour for binaries. If this flag is enabled and there is a none-default
target enabled, the binaries for each target are preserved and installed
with their target as suffix. A symlink is created for the binary name to a
wrapper, which does execute the real binary based on a set environment
variable. Following alternative implementations have not been selected:
* no wrapper: This would mean, that the installed binaries change, depending
on the selected targets. Since some binaries have target specific output,
this would reduce the possible targets for depending packages.
* a variable to control the packages with wrapped binaries: This has the
same effect as a USE flag, but requires the user to look into an additional
location to see, if a package gets wrapped binaries or not.
If a package has dependencies, then those dependencies are required to have
at least the same targets enabled as the package. This makes sure, that
the needed libs for that target do exist. The alternative to go without
those dependencies was not choosen, because this would result in compile
failures due to missing libs for the specified target and in the need for
the user to manually find the needed libs and to install them with the needed
An enabled USE flag called "multilib" does restrict any cross-compilation
and compiles and installs the package for the default target. The added
USE flags still exist, but are ignored. This allows packages to do their
own cross-compilation without conflicting with this feature. The
alternative to not have such a flag would make it much harder for certain
packages (e.g. gcc, glibc or linux-headers) to be transferred to this
To allow packages, which already compile and/or install files for different
targets, to use this future EAPI, the multilib USE flag is used as a special
flag to indicate, that this package already does the needed steps, so that
the package manager wont attempt to additionally do this.
Further backward compatibility issues are not known.
A reference implementation is done in a portage branch. The code can be
found at [#1].
An overlay containing an ebuild and the needed profile details can be
found via layman. It is called "multilib-portage". The docs dir contains
basic setup instructions. For help with this overlay, ask in [#2].
A stage 4 qemu image can be found on the Gentoo distfiles mirrors [#3].
.. [#1] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib
.. [#2] IRC network: Freenode, IRC channel: #gentoo-multilib-overlay
.. [#3] http://distfiles.gentoo.org/experimental/amd64/qemu/ contains
multilib-amd64-qemu-2012-01-04.tar.lzma with DIGESTS file and
signature. Those file are also on any other distfiles mirror
including the experimental dir.
This document has been placed in the public domain.