There are a few important variables that we will use throughout this section.

There are a few important variables that we will use throughout this section

</p>

which we discussed earlier: <c>CBUILD</c>, <c>CHOST</c>, <c>CTARGET</c>,

<c>ROOT</c>, and <c>PORTAGE_CONFIGROOT</c>.

<table>

</p>

 <tr>

  <th>Variable</th>

<p>

  <th>Meaning</th>

You can set this all by hand, but that obviously gets quite tedious very

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

<p>

You can either set this all by hand, but that obviously gets quite tedious very

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.

</p>

<p>

Something like the following works well to start, and can be tweaked as

desired:

</p>

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

<p>

Cross-compiling a system generally involves two directory trees.  The first is

Cross-compiling a system generally involves two directory trees. The differences

where all development files are normally installed.  This is your sysroot.  The

between them can be difficult to understand, but they are important concepts

other tree is where only your runtime files are installed.  You emerge all of

to cross-compiling.

your fun packages into your sysroot (without trimming down any files), and then

</p>

either install via binary packages or copying files by hand all the stuff you

need in your runtime tree.

<p>

The first tree to consider is sysroot. Please read the

<uri link="intro.xml">Introduction</uri> chapter for the sysroot definition.

</p>

<p>

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.

historically proven to be problematic.  Yes, it works most of the time, but

historically proven to be problematic in enough corner cases to be discouraged

the corner cases are why this method is discouraged.  In the embedded handbook,

for practical use.

we'll assume you're using the sysroot as your development ROOT.

-->

<title>Intro: crossdev-wrappers</title>

<title>Intro: crossdev's wrappers</title>

compile using emerge. PORTAGE_CONFIGROOT and ROOT both point to the 

compile using emerge. <c>PORTAGE_CONFIGROOT</c> and <c>ROOT</c> both point to the 

SYSROOT.

<c>SYSROOT</c> by default, but you can change that with the example script above.

We can use these tools for both installing into your development root 

If you had merged via crossdev an <c>armv4tl-softfloat-linux-gnueabi</c>

(sysroot) and into your runtime root.  For the latter, simply specify 

toolchain, you would invoke emerge normally, but prepend "emerge" with the

by using the <c>--root</c> option. For example if you had merged via crossdev 

<c>ctarget</c> prefix:

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:

By default the wrappers will link to the generic embedded profile. This 

By default crossdev will link to the generic embedded profile. This 

And naturally to change settings for the target system like USE flags, 

To change additional portage settings like <c>USE</c> flags, <c>FEATURES</c>, and <c>VIDEO_CARDS</c>, 

FEATURES, and VIDEO_CARDS. We would edit the standard portage config files.

we would edit the standard portage config files, but this time wherever

<c>PORTAGE_CONFIGROOT</c> points.

<pre caption="${SYSROOT}/etc/make.conf">

<pre caption="${PORTAGE_CONFIGROOT}/etc/make.conf">

# <i>$EDITOR ${SYSROOT}/etc/make.conf</i>

# <i>$EDITOR ${PORTAGE_CONFIGROOT}/etc/make.conf</i>

Sometimes there are some additional tests we need override for configure

Sometimes there are some additional, cross-compile-incomplatible tests we

scripts. To do this the wrappers export a few variables to force the test to get

need override for configure scripts. To do this crossdev exports a few variables

the answer it should. This will help prevent bloat in packages which add local

to force the test to get the answer it should. This will help prevent bloat

functions to workaround issues it assumes your system has because it could not

in packages which add local functions to workaround issues it assumes your

run the test. From time to time you may find you need to add additional

<e>target</e> system has because it could not run the test while cross-compiling

variables to these files in <path>/usr/share/crossdev/include/site/</path> to

(because, of course, it's not running on the target system). From time to

get a package to compile. To figure out the variable you need to add, it's often

time you may find you need to add additional variables to these files in

as simple as greping the configure script for the autoconf variable and adding

<path>/usr/share/crossdev/include/site/</path> to get a package to compile.

it to the appropriate target file. This becomes obvious after the first few

To figure out the variable you need to add, it's often as simple as greping

times of doing it.

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.

If you want to uninstall and delete your work, then you can safely remove the

You can safely remove the sysroot tree at any time without affecting any

sysroot tree without affecting any native packages.  See also the section in

native packages.  See the section in the

the <uri link="cross-compiler.xml">crossdev guide</uri> about uninstalling.

<uri link="cross-compiler.xml">crossdev guide</uri> about uninstalling for

more information.

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