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 multilib-portage. > > 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 > suspect. 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. -- Thomas Sachau Gentoo Linux Developer
GLEP: XXX Title: Crosscompile support for multilib profiles Version: $Revision: 1.4 $ Last-Modified: $Date: 2003/07/19 12:09:20 $ Author: Thomas Sachau <to...@gentoo.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 24 Jun 2012 Post-History: 2-Jun-2003 Abstract ======== 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. Motivation ========== 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. Specification ============= 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. Exmaple: profile: amd64/multilib 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: DEPEND="dev-libs/a[multilib_abi_x86]" Rationale ========= 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 target. 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 future EAPI. Backwards Compatibility ======================= 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. Reference Implementation ======================== 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]. References ========== .. [#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. Copyright ========= This document has been placed in the public domain.
signature.asc
Description: OpenPGP digital signature
