Attachment 217361 Details for Bug 302129 – Lots of changes to cross-compiling-packages.xml.

[patch] Lots of changes to cross-compiling-packages.xml.

0008-Lots-of-changes-to-cross-compiling-packages.xml.patch (text/plain), 12.34 KB, created by Jacob Godserv on 2010-01-25 03:12:51 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jacob Godserv

Created: 2010-01-25 03:12:51 UTC

Size: 12.34 KB

patch

obsolete

>From 5c0b301635c81dfb4cb5dc6470a64d9e7673968d Mon Sep 17 00:00:00 2001
>From: Jacob Godserv <jacobgodserv@gmail.com>
>Date: Thu, 21 Jan 2010 13:09:59 -0500
>Subject: [PATCH 8/9] Lots of changes to cross-compiling-packages.xml.
>
>* Removed duplicate definitions, and moved new ones to intro.xml. Also replaced definition for sysroot with the better one from cross-compiling-packages.xml
>* More detailed information on how to configure the environment for cross-compiling.
>* Updated instructions for crossdev 20100108.
>* Fixed a bug: PORTAGE_CONFIGROOT, not SYSROOT, is what points portage to its configs
>* Generally clarified wording.
>---
> .../embedded/handbook/cross-compiling-packages.xml | 182 ++++++++++++--------
> .../proj/en/base/embedded/handbook/intro.xml | 8 +-
> 2 files changed, 121 insertions(+), 69 deletions(-)
>
>diff --git a/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-packages.xml b/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-packages.xml
>index f107e48..7ffecab 100644
>--- a/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-packages.xml
>+++ b/xml/htdocs/proj/en/base/embedded/handbook/cross-compiling-packages.xml
>@@ -17,39 +17,44 @@ Leverage Portage as a cross-compiling package manager.
> <body>
> 
> 
>-There are a few important variables that we will use throughout this section.
>-
>-
>-<table>
>- <tr>
>- <th>Variable</th>
>- <th>Meaning</th>
>- </tr>
>- <tr>
>- <ti>CBUILD</ti>
>- <ti>Platform you are building on</ti>
>- </tr>
>- <tr>
>- <ti>CHOST</ti>
>- <ti>Platform you are compiling for</ti>
>- </tr>
>- <tr>
>- <ti>ROOT</ti>
>- <ti>The virtual <path>/</path> you are installing into</ti>
>- </tr>
>- <tr>
>- <ti>PORTAGE_CONFIGROOT</ti>
>- <ti>
>- The virtual <path>/</path> portage can find its config files (like
>- <path>make.conf</path>)
>- </ti>
>- </tr>
>-</table>
>-
>-
>-You can either set this all by hand, but that obviously gets quite tedious very
>+There are a few important variables that we will use throughout this section
>+which we discussed earlier: <c>CBUILD</c>, <c>CHOST</c>, <c>CTARGET</c>,
>+<c>ROOT</c>, and <c>PORTAGE_CONFIGROOT</c>.
>+
>+
>+
>+You can set this all by hand, but that obviously gets quite tedious very
> quickly. A better idea is to stick these into a shell script so you can avoid
>-typing it out all the time.
>+typing it out all the time. Having it all in a shell script also allows
>+you to set autoconf test assumptions to skip ./configure tests that are
>+troublesome for cross-compiling.
>+
>+
>+
>+Something like the following works well to start, and can be tweaked as
>+desired:
>+
>+<pre caption="set_environment.sh">
>+export CBUILD="powerpc-unknown-linux-gnu"
>+export CHOST="sh4-unknown-linux-gnu"
>+export CTARGET="$CHOST"
>+export SYSROOT="/usr/$CHOST"
>+export ROOT="/path/to/some/dir"
>+export PORTAGE_CONFIGROOT="${SYSROOT}"
>+
>+echo " CBUILD: "$CBUILD
>+echo " CTARGET: "$CTARGET
>+echo " CHOST: "$CHOST
>+echo " SYSROOT: "$SYSROOT
>+echo " ROOT: "$ROOT
>+echo " PORTAGE_CONFIGROOT: "$PORTAGE_CONFIGROOT
>+</pre>
>+<note>
>+If you're not sure what any of these do, please read the
>+<uri link="intro.xml">Introduction</uri> chapter.
>+</note>
>+
>+
> 
> 
> </body>
>@@ -60,12 +65,20 @@ typing it out all the time.
> <body>
> 
> 
>-Cross-compiling a system generally involves two directory trees. The first is
>-where all development files are normally installed. This is your sysroot. The
>-other tree is where only your runtime files are installed. You emerge all of
>-your fun packages into your sysroot (without trimming down any files), and then
>-either install via binary packages or copying files by hand all the stuff you
>-need in your runtime tree.
>+Cross-compiling a system generally involves two directory trees. The differences
>+between them can be difficult to understand, but they are important concepts
>+to cross-compiling.
>+
>+
>+
>+The first tree to consider is sysroot. Please read the
>+<uri link="intro.xml">Introduction</uri> chapter for the sysroot definition.
>+
>+
>+
>+The second tree is real root. This one is much simpler to understand: it's
>+where you're trying to create a bootable stage3-like installation of Gentoo
>+that you can copy to your target device.
> 
> 
> 
>@@ -73,12 +86,25 @@ The common convention is to use your <path>/usr/CTARGET/</path> tree as your
> sysroot as the include/library directories in this tree are already encoded
> into the gcc cross-compiler for searching. You could use another directory
> and then add custom -I/-L paths to your CPPFLAGS/LDFLAGS, but this has
>-historically proven to be problematic. Yes, it works most of the time, but
>-the corner cases are why this method is discouraged. In the embedded handbook,
>-we'll assume you're using the sysroot as your development ROOT.
>+historically proven to be problematic in enough corner cases to be discouraged
>+for practical use.
> 
> 
> 
>+A less common convention, but common nonetheless, is to set <c>ROOT</c> and
>+<c>SYSROOT</c> to exactly the same thing. This seems odd, given the definitions
>+and differences of <c>ROOT</c> and <c>SYSROOT</c>. Remember from the
>+<uri link="intro.xml">Introduction</uri> chapter that the cross-compiler
>+sometimes wants libraries preinstalled to <c>SYSROOT</c> first before they're
>+used in <c>ROOT</c>, which often is enough aggravation to cause some to install
>+everything to <c>SYSROOT</c>. What ends up happening is a mixed, somewhat messy
>+<c>ROOT</c>/<c>SYSROOT</c> tree is installed to <c>SYSROOT</c>. However, as
>+long as you're generating binary packages, you can later ignore the
>+<c>SYSROOT</c>/<c>ROOT</c> directories entirely and install a new <c>ROOT</c>
>+elsewhere using those binary packages.
>+
>+
> </body>
> </section>
> 
> <section>
>-<title>Intro: crossdev-wrappers</title>
>+<title>Intro: crossdev's wrappers</title>
> <body>
> 
> 
> These are simple wrapper scripts that will setup the environment 
> variables to point to the right places for you to be able to cross 
>-compile using emerge. PORTAGE_CONFIGROOT and ROOT both point to the 
>-SYSROOT.
>+compile using emerge. <c>PORTAGE_CONFIGROOT</c> and <c>ROOT</c> both point to the 
>+<c>SYSROOT</c> by default, but you can change that with the example script above.
> 
> 
>+<warn>
>+crossdev's wrappers automatically configure <c>CBUILD</c> and <c>CHOST</c>.
>+Do not set these by hand in your environment! (Bug #301751 states that CTARGET
>+is not set, so you may wish to do so by hand.)
>+</warn>
>+
> <pre caption="crossdev-wrappers">
> # echo sys-devel/crossdev-wrappers >> /etc/portage/package.keywords
> # emerge crossdev-wrappers
> </pre>
>+<note>
>+crossdev-wrappers has been merged into crossdev as of version 20100108. If
>+you have crossdev 20100108 or later, crossdev-wrappers should not and will
>+not be installed.
>+</note>
>+
>+
>+We can use these tools for installing into whichever directory <c>ROOT</c>
>+points to. You can set <c>ROOT</c> equal to <c>SYSROOT</c> for installation
>+into sysroot, or <c>ROOT</c> to a different directory for installation into
>+a "runtime" root.
>+
> 
> 
>-We can use these tools for both installing into your development root 
>-(sysroot) and into your runtime root. For the latter, simply specify 
>-by using the <c>--root</c> option. For example if you had merged via crossdev 
>-an <c>armv4tl-softfloat-linux-gnueabi</c> toolchain you would then invoke the 
>-command just like normal emerge. But using the <c>ctarget</c> prefix:
>+If you had merged via crossdev an <c>armv4tl-softfloat-linux-gnueabi</c>
>+toolchain, you would invoke emerge normally, but prepend "emerge" with the
>+<c>ctarget</c> prefix:
> 
> 
> <pre caption="CTARGET-emerge">
>@@ -124,7 +166,7 @@ dependencies from being pulled into the deptree.
> 
> 
> 
>-By default the wrappers will link to the generic embedded profile. This 
>+By default crossdev will link to the generic embedded profile. This 
> is done to simpilify things, but the user may wish to use a more 
> advanced targeted profile. In order to do that we can update the profile symlink.
> 
>@@ -134,25 +176,28 @@ advanced targeted profile. In order to do that we can update the profile symlink
> </pre>
> 
> 
>-And naturally to change settings for the target system like USE flags, 
>-FEATURES, and VIDEO_CARDS. We would edit the standard portage config files.
>+To change additional portage settings like <c>USE</c> flags, <c>FEATURES</c>, and <c>VIDEO_CARDS</c>, 
>+we would edit the standard portage config files, but this time wherever
>+<c>PORTAGE_CONFIGROOT</c> points.
> 
> 
>-<pre caption="${SYSROOT}/etc/make.conf">
>-# $EDITOR ${SYSROOT}/etc/make.conf
>+<pre caption="${PORTAGE_CONFIGROOT}/etc/make.conf">
>+# $EDITOR ${PORTAGE_CONFIGROOT}/etc/make.conf
> </pre>
> 
> 
>-Sometimes there are some additional tests we need override for configure
>-scripts. To do this the wrappers export a few variables to force the test to get
>-the answer it should. This will help prevent bloat in packages which add local
>-functions to workaround issues it assumes your system has because it could not
>-run the test. From time to time you may find you need to add additional
>-variables to these files in <path>/usr/share/crossdev/include/site/</path> to
>-get a package to compile. To figure out the variable you need to add, it's often
>-as simple as greping the configure script for the autoconf variable and adding
>-it to the appropriate target file. This becomes obvious after the first few
>-times of doing it.
>+Sometimes there are some additional, cross-compile-incomplatible tests we
>+need override for configure scripts. To do this crossdev exports a few variables
>+to force the test to get the answer it should. This will help prevent bloat
>+in packages which add local functions to workaround issues it assumes your
>+<e>target</e> system has because it could not run the test while cross-compiling
>+(because, of course, it's not running on the target system). From time to
>+time you may find you need to add additional variables to these files in
>+<path>/usr/share/crossdev/include/site/</path> to get a package to compile.
>+To figure out the variable you need to add, it's often as simple as greping
>+the configure script for the autoconf variable (which often begins with "ac_")
>+and adding it to the appropriate target file. This becomes easy once you
>+know what you're looking for.
> 
> 
> </body>
>@@ -163,9 +208,10 @@ times of doing it.
> <body>
> 
> 
>-If you want to uninstall and delete your work, then you can safely remove the
>-sysroot tree without affecting any native packages. See also the section in
>-the <uri link="cross-compiler.xml">crossdev guide</uri> about uninstalling.
>+You can safely remove the sysroot tree at any time without affecting any
>+native packages. See the section in the
>+<uri link="cross-compiler.xml">crossdev guide</uri> about uninstalling for
>+more information.
> 
> 
> </body>
>diff --git a/xml/htdocs/proj/en/base/embedded/handbook/intro.xml b/xml/htdocs/proj/en/base/embedded/handbook/intro.xml
>index 89dbc3e..ea01a16 100644
>--- a/xml/htdocs/proj/en/base/embedded/handbook/intro.xml
>+++ b/xml/htdocs/proj/en/base/embedded/handbook/intro.xml
>@@ -174,7 +174,13 @@ PDA we wanted to develop for, the above table would look like:
> </dd>
> 
> <dt><c>sysroot: system root</c></dt>
>-<dd>The root directory a compiler uses to find its standard headers and libraries. Sometimes a compiler wants more than just standard headers and libraries in this directory, as though they were "standard" too. We'll explain how to resolve this when it happens in future chapters.</dd>
>+<dd>
>+	This is where all the cross-compiler libraries and headers are installed.
>+	In other words, every library and header the cross-compiler needs to generate
>+	cross-compiled binaries are put here. In theory, this means the toolchain
>+	is good enough. In practice, the cross-compiler often wants some of a package's
>+	library dependancies, such as ncurses, installed into sysroot first.
>+</dd>
> 
> <dt><c>hardfloat</c></dt>
> <dd>The system has a hardware Floating Point Unit (FPU) to handle floating point math.</dd>
>-- 
>1.6.4.4
>

Actions: View | Diff

Attachments on bug 302129: 217350 | 217352 | 217354 | 217356 | 217358 | 217359 | 217360 | 217361 | 217363 | 240005