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 06-29-2012, 02:30 PM
Thomas Sachau
 
Default GLEP draf for cross-compile support in multilib profiles (was: spec draft for cross-compile support in future EAPI (EAPI-5))

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 <tommy@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.
 
Old 06-30-2012, 05:29 PM
Matt Turner
 
Default GLEP draf for cross-compile support in multilib profiles (was: spec draft for cross-compile support in future EAPI (EAPI-5))

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?

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?

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?

Thanks,
Matt
 

Thread Tools




All times are GMT. The time now is 05:09 AM.

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