The Embedded Linux Development Kit (ELDK)
includes the GNU cross development tools, such as the compilers,
binutils, gdb, etc., and a number of pre-built target tools and
libraries necessary to provide some functionality on the target
system.
It is provided for free with full source code, including all patches,
extensions, programs and scripts used to build the tools.
Packaging and installation is based on the RPM package manager.
The ELDK is available
The ELDK can be installed onto and operate with the following
operating systems:
Users also reported successful installation and use of the ELDK on
the following host systems:
- SuSE Linux 7.2, 7.3, 8.x
- Mandrake 8.2
- Slackware 8.1beta2
- FreeBSD 5.0
- Debian 3.0 (Woody)
- Gentoo Linux 1.4_rc2
Note: It may be necessary, and usually is recommended, to install the
latest available software updates on your host system. For example on
RedHat systems, run the "up2date" tool.
The ELDK includes target components and supports code generation for
the following PowerPC types of processors:
- ppc_8xx = MPC8xx processors
- ppc_82xx = MPC82xx processors
- ppc_4xx = IBM 4xx processors without FPU
- ppc_4xxFP = IBM 4xx processors with FPU
- ppc_7xx = 7xx processors
- ppc_74xx = 74xx processors
There is also an ELDK for ARM and MIPS systems.
Stable versions of the ELDK are distributed in the form of an ISO
image, which can be either burned onto a CD or mounted directly,
using the loopback Linux device driver (Linux host only).
Development versions of the ELDK are available as directory trees so
it is easy to update individual packages; instructions for download
of these trees and creation of ISO images from it is described in section 1.4.2. Downloading the ELDK.
The ELDK contains an installation utility and a number of RPM
packages, which are installed onto the hard disk of the cross
development host by the installation procedure. The RPM packages can
be logically divided into two parts:
- Embedded Linux Development Tools (ELDT)
- Target components
The first part contains the cross development tools that are executed
on the host system. Most notably, these are the GNU cross compiler,
binutils, and GDB. For a full list of the provided ELDT packages,
refer to section 1.8.1. List of ELDT Packages below.
The target components are pre-built tools and libraries which are
executed on the target system. The ELDK includes necessary target
components to provide a minimal working NFS-based environment for the
target system. For a list of the target packages included in the
ELDK, refer to section 1.8.2. List of Target Packages below.
The ELDK several independent sets of the target packages, one
for each supported target architecture
CPU family. Each set has been built using
compiler code generation and optimization options specific to the
respective target CPU family.
To download the ELDK from the development directory tree and create
an ISO image that can be burned on CD-ROM, please proceed as follows:
Change to a directory with sufficient free disk space; for the
PowerPC version of the ELDK you need about 700 MB, or twice as much
(1.4 GB) if you also want to create an ISO image in this directory.
Use the ncftp FTP client to download the whole
ELDK directory tree:
bash$ ncftp ftp://ftp.leo.org/pub/eldk/3.0/
...
ncftp /pub/eldk > bin
ncftp /pub/eldk > get -R eldk-ppc-linux-x86
...
ncftp /pub/eldk > bye
Please download the contents of the
eldk-ppc-linux-x86 directory
for PowerPC targets and x86 Linux hosts; other options are
eldk-ppc-solaris-sparc
for PowerPC targets and SPARC Solaris hosts or
eldk-arm-linux-x86
for ARM targets and x86 Linux hosts.
There are a few executable files (binaries and scripts) in the ELDK
tree. Make sure they have the execute permissions set in your local
copy:
bash$ for file in \
> tools/bin/rpm \
> tools/usr/lib/rpm/rpmd \
> install \
> ELDK_MAKEDEV \
> ELDK_FIXOWNER
> do
> chmod +x eldk-ppc-linux-x86/$file
> done
Now create an ISO image from the directory tree:
bash$ mkisofs \
> -A "ELDK-3.0 -- Target: PowerPC -- Host: x86 Linux" \
> -P "(C) `date "+%Y"` DENX Software Engineering, www.denx.de" \
> -p "`id -nu`@`hostname` -- `date`" \
> -V eldk-ppc-linux-x86 \
> -l -J -R -o eldk-ppc-linux-x86.ISO eldk-ppc-linux-x86
This will create an ISO image
eldk-ppc-linux-x86.ISO in your local directory
that can be burned on CD or mounted using the loopback device and
used for installation as described above. Of course you can use the
local copy of the directory tree directly for the installation, too.
Please refer to section 1.9.2. Setting Up ELDK Build Environment
for instructions on obtaining the
build environment needed to re-build the ELDK from scratch.
The initial installation is performed using the install utility
located in the root of the ELDK ISO image directory tree. The install
utility has the following syntax:
./install [-d <dir>] [<cpu_family>] [<cpu_family2>] ...
-d <dir> | Specifies the root directory of the ELDK being installed. If omitted, the ELDK goes into the current directory. |
<cpu_family> | Specifies the target CPU family the user desires to install. If one or more <cpu_family> parameters are specified, only the target components specific to the respective CPU families are installed onto the host. If omitted, the target components for all supported target architecture CPU families are installed. |
Note: Make sure that the "exec"
option to the mount command is in effect when mounting the ELDK ISO image. Otherwise the install
program cannot be executed.
You can install the ELDK to any empty directory you wish, the only
requirement being that you have to have write and execute permissions
on the directory. The installation process does not require
superuser privileges.
Depending on the parameters the install utility is invoked with, it
installs one or more sets of target components. The ELDT packages are
installed in any case.
Refer to section 1.5. Working with ELDK
for a usage sequence of the ELDK.
Note: If you intend to use the installation as root filesystem exported
over NFS, then you now have to finish the configuration of the ELDK
following the instructions in ELDK-NFS.
The ELDK has an RPM-based structure. This means that on the ISO
image, individual components of the ELDK are in the form of RPM
packages, and after installation, the ELDK maintains its own database
which contains information about installed packages. The RPM database
is kept local to the specific ELDK installation, which allows you to
have multiple independent ELDK installations on your host system.
(That is, you can install several instances of ELDK under different
directories and work with them independently). Also, this provides
for easy installation and management of individual ELDK packages.
To list the installed ELDK RPM packages, use the following command:
bash$ ${CROSS_COMPILE}rpm -qa
To remove an ELDK package, use the following command:
bash$ ${CROSS_COMPILE}rpm -e <package_name>
To install a package, use the following command:
bash$ ${CROSS_COMPILE}rpm -i <package_file_name>
To update a package, use the following command:
bash$ ${CROSS_COMPILE}rpm -U <package_file_name>
For the above commands to work correctly, it is crucial that the
correct rpm
binary gets invoked. In case of
multiple ELDK installations and RedHat-based host system, there may
well be several rpm
tools installed on the host
system.
You must make sure, either by using an explicit path or by having set
an appropriate PATH
environment variable, that
when you invoke rpm
to install/remove components
of a ELDK installation, it is the ELDK's rpm
utility that gets actually invoked. The rpm
utility is located in the bin
subdirectory
relative to the ELDK root installation directory.
To avoid confusion with the host OS (RedHat) rpm
utility, the ELDK creates symlinks to its rpm
binary with the names such that it could be invoked using the
${CROSS_COMPILE}rpm
notation, for all supported
$CROSS_COMPILE values.
The standard (host OS) rpm
utility allows various
macros and configuration parameters to specified in
user-specific ~/.rpmrc and ~/.rpmmacros files. The ELDK
rpm tool also has this capability, but the names
of the user-specific configuration files
are ~/.eldk_rpmrc and ~/.eldk_rpmmacros, respectively.
To remove the entire ELDK installation, use the following command
while in the ELDK root directory:
bash$ rm -rf <dir>
where <dir>
specifies the root directory of the ELDK to be
removed.
After the initial installation is complete, all you have to do to
start working with the ELDK is to export the
CROSS_COMPILE
environment variable.
Optionally, you may wish to add the bin and usr/bin directories of
your ELDK installation to the value of the PATH
environment variable. For instance, a sample ELDK installation and
usage scenario looks as follows:
- Create a new directory where the ELDK is to be installed:
bash$ mkdir /opt/eldk
- Mount a CD or an ISO image with the distribution:
bash$ mount /dev/cdrom /mnt/cdrom
- Run the installation utility included on the distribution to
install into a specified directory.
bash$ /mnt/cdrom/install -d /opt/eldk
- After the installation utility completes, export the
CROSS_COMPILE
variable:
bash$ export CROSS_COMPILE=ppc_8xx-
The trailing '-' character
in the CROSS_COMPILE
variable value is optional
and has no effect on the cross tools behavior.
- Add the directories /opt/eldk/usr/bin and /opt/eldk/bin
to
PATH
:
bash$ PATH=$PATH:/opt/eldk/usr/bin:/opt/eldk/bin
- Compile a file:
bash$ ${CROSS_COMPILE}gcc -o hello_world hello_world.c
You can also call the cross tools using the generic prefix ppc-linux-
for example:
bash$ ppc-linux-gcc -o hello_world hello_world.c
The value of the CROSS_COMPILE
variable
must correspond to the target CPU family you want the cross tools to
work for. Refer to the table below for the supported
CROSS_COMPILE
variable values:
1.5.A Table of possible values for $CROSS_COMPILE
CROSS_COMPILE Value | Predefined Compiler Flag | FPU present or not |
ppc_8xx- | -mcpu=860 | No |
ppc_82xx- | -mcpu=603 | Yes |
ppc_4xx- | -mcpu=403 | No |
ppc_4xxFP- | -mcpu=403 | Yes |
ppc_7xx- | -mcpu=750 | Yes |
ppc_74xx- | -mcpu=7400 | Yes |
No special actions are required from the user to switch between
multiple ELDK installations on the host system. Which ELDK
installation is used is determined entirely by the filesystem
location of the binary that is being invoked. This approach can be
illustrated using the following example:
Assume the directory
/work/denx_tools/usr/bin, where the ppc-linux-gcc
compiler binary has been installed,
is a part of the PATH
environment variable. The
user types the command as follows:
bash$ ppc_8xx-gcc -c myfile.c
To load the correct include files, find the correct libraries, spec
files, etc., the compiler needs to know the ELDK root directory. The
compiler finds out this information by analyzing the shell command it
was invoked with ( ppc_8xx-gcc
- without
specifying the explicit path in this example) and, if needed, the
value of the PATH
environment variable. Thus, the
compiler knows that it has been executed from the
/work/denx_tools/usr/bin directory.
Then, it knows that the compiler is installed in the usr/bin
subdirectory of the root installation directory, so the ELDK the
compiler is part of has been installed in the subdirectories of the
/work/denx_tools directory. This means
that the target include files are in
/work/denx_tools/<target_cpu_variant>/usr/include,
and so on.
The target components of the ELDK can be mounted via NFS as the root
file system for your target machine. For instance, for a 8xx-based
target, and assuming the ELDK has been intalled into the
/opt/eldk directory, you can
use the following directory as the NFS-based root file system:
/opt/eldk/ppc_8xx
Before the NFS-mounted root file system can work, you must create
necessary device nodes in the
<ELDK_root>/<target_cpu_variant>/dev
directory. This process requires the superuser privileges and thus
could not have been done by the installation procedure. To facilitate
creation of the device nodes, the ELDK provides a script named
ELDK_MAKEDEV
, which is located in the root
of the ELDK distribution ISO image. To create the device nodes, you
should invoke this script while in the appropriate dev subdirectory
where the the device nodes are to be created. For instance, to create
the device nodes for a MPC8xx
based system, use the following commands:
bash# cd /opt/eldk/ppc_8xx/dev
bash# /mnt/cdrom/ELDK_MAKEDEV
Some of the target utilities included in the ELDK, such as
mount
and su
, have the SUID bit
set. This means that when run, they will have privileges of the file
owner of these utilities. That is, normally, they will have the
privileges of the user who installed the ELDK on the host system.
However, for these utilities to work properly, it is required that
they have the superuser privileges. This means that if the ELDK has
been installed not by the superuser, the file owner of the target
ELDK utilities that have the SUID bit set must be changed to
root
before a target component may be mounted as
the root file system. The ELDK distribution image contains an
ELDK_FIXOWNER
script, which you can use to change
file owners of all the appropriate files of the ELDK installation to
root. You should invoke this script while in the root ELDK
installation directory. Please note that you must have superuser
privileges to run this script. For instance, if you have installed
the ELDK in the /opt/eldk
directory, you can use the following command:
bash# cd /opt/eldk
bash# /mnt/cdrom/ELDK_FIXOWNER
1.7.1. ELDK Source Distribution
The ELDK is distributed with the full sources of all the components,
so you may rebuild any ELDK packages. The sources are provided in the
form of SRPM packages, distributed as a separate ISO image.
To rebuild a target or ELDT package, you must first install the
appropriate source RPM package from the ISO image into the ELDK
environment. This can be done using the following command:
bash$ ${CROSS_COMPILE}rpm -i /mnt/cdrom/SRPMS/<source_rpm_file_name>.src.rpm
After an ELDK source RPM is installed using the above command, its
spec file and sources can be found in the subdirectories of the
<ELDK_root>/usr/src/denx subdirectory.
The sections that follow provide detailed instructions on rebuilding
ELDT and target components of the ELDK.
All the target packages allow for rebuilding
from the provided source RPM packages. At first you have to install the Source RPM itself:
bash$ ${CROSS_COMPILE}rpm -iv <package_name>.src.rpm
Then you can rebuild the binary target RPM using the following command
from the ELDK environment:
bash$ ${CROSS_COMPILE}rpmbuild -ba <package_name>.spec
In order for the rebuilding process to work correctly, the following
conditions must be met:
- The $CROSS_COMPILE environment variable
must be set as appropriate for the target CPU family.
- The <ELDK_root>/usr/ppc-linux/bin
directory must be in
PATH
before the
/usr/bin directory. This is to make sure that
the command gcc
results in the fact that the
ELDK cross compiler is invoked, rather than the host
gcc
.
All the ELDT packages allow for rebuilding from the provided source
RPM packages using the following command from the ELDK environment:
bash$ ${CROSS_COMPILE}rpmbuild -ba <package_name.spec>
In order for the rebuilding process to work correctly, the following
important condition must be met:
- The <ELDK_root>/usr/ppc-linux/bin
directory must NOT be in
PATH
. This is to make sure that the command
gcc
causes invokation of the host
gcc
, rather than the ELDK cross compiler.
Package Name | Package Version |
cpp | 3.2.2-2a_1 |
binutils | 2.13.90.0.18-6_1 |
gcc | 3.2.2-2a_1 |
gcc-c++ | 3.2.2-2a_1 |
gdb | 5.2.1-4b_4 |
genext2fs | 1.3-4 |
ldd | 0.1-1 |
make | 3.79.1-17_1 |
make-doc | 3.79.1-17_1 |
mkcramfs | 0.0.1_1 |
mkimage | 0.3.1-1 |
mtd_utils | 1-1 |
rpm | 4.1.1-1.8xa_1 |
rpm-build | 4.1.1-1.8xa_1 |
Package Name | Package Version |
bash | 2.05b-20.1a_1 |
bash-doc | 2.05b-20.1a_1 |
binutils | 2.13.90.0.18-6_1 |
boa | 0.94.12-1 |
busybox | 0.60.5-1 |
cpio | 2.4.2-28_1 |
cpp | 3.2.2-2a_2 |
cracklib | 2.7-18_1 |
cracklib-dicts | 2.7-18_1 |
db4 | 4.0.14-14_1 |
db4-devel | 4.0.14-14_1 |
db4-utils | 4.0.14-14_1 |
diffutils | 2.8.1-3_1 |
e2fsprogs | 1.27-9_1 |
e2fsprogs-devel | 1.27-9_1 |
expat | 1.95.4-1_1 |
expat-devel | 1.95.4-1_1 |
fileutils | 4.1.9-11_1 |
findutils | 4.1.7-7_1 |
ftp | 0.17-15_1 |
gawk | 3.1.1-4_1 |
gcc | 3.2.2-2a_2 |
gcc-c++ | 3.2.2-2a_2 |
gdb | 5.2.1-4b_3 |
gdbserver | 5.2.1-4b_3 |
glib | 1.2.10-9_1 |
glib-devel | 1.2.10-9_1 |
glibc-common | 2.3.1-51a_2 |
glibc-devel | 2.3.1-51a_2 |
glibc | 2.3.1-51a_2 |
glibc-profile | 2.3.1-51a_2 |
glibc-utils | 2.3.1-51a_2 |
glib2 | 2.2.1-1_1 |
glib2-devel | 2.2.1-1_1 |
grep | 2.5.1-4_1 |
groff | 1.18-6_1 |
gzip | 1.3.3-5a_1 |
httpd | 2.0.40-21.3b_1 |
httpd-devel | 2.0.40-21.3b_1 |
httpd-manual | 2.0.40-21.3b_1 |
initscripts | 6.95-1l_2 |
iproute | 2.4.7-5_1 |
iputils | 20020124-8_1 |
kernel-headers | 2.4.24-6 |
kernel-source | 2.4.24-6 |
krb5-devel | 1.2.7-14_1 |
krb5-libs | 1.2.7-14_1 |
less | 358-28 |
libcap | 1.10-12_1 |
libcap-devel | 1.10-12_1 |
libstdc++ | 3.2.2-2a_2 |
libstdc++-devel | 3.2.2-2a_2 |
libtermcap | 2.0.8-31_1 |
libtermcap-devel | 2.0.8-31_1 |
libuser | 0.51.7-1_1 |
libuser-devel | 0.51.7-1_1 |
logrotate | 3.6.5-2_1 |
mailcap | 2.1.12-1 |
make | 3.79.1-17_1 |
man | 1.5k-6_1 |
microwindows | 0.90-2 |
microwindows-fonts | 0.90-1 |
mingetty | 1.00-3 |
mktemp | 1.5-16 |
modutils | 2.4.22-8_1 |
modutils-devel | 2.4.22 |
mount | 2.11y-2_1 |
mtd_utils | 1-1 |
ncompress | 4.2.4-31 |
ncurses | 5.2-28_1 |
ncurses-devel | 5.2-28_1 |
ncurses-c++-devel | 5.2-28_1 |
net-tools | 1.60-7_1 |
nfs-utils | 1.0.1-3.9_1 |
ntp | 4.1.1a-9_1 |
openssl | 0.9.7a-5a_1 |
openssl-devel | 0.9.7a-5a_1 |
pam | 0.75-48a_1 |
pam-devel | 0.75-48a_1 |
passwd | 0.67-3_1 |
pciutils | 2.1.10-2_1 |
pciutils-devel | 2.1.10-2_1 |
pcmcia-cs | 3.2.1-2 |
popt | 1.7-1 |
portmap | 4.0-46_1 |
procps | 2.0.7-25_1 |
psmisc | 20.2-6_1 |
rdate | 1.2-5 |
readline | 4.3-3_1 |
readline-devel | 4.3-3_1 |
routed | 0.17-12_1 |
rsh | 0.17-10_1 |
rsh-server | 0.17-10_1 |
sed | 3.02-13_1 |
SELF | 1.0-3 |
setup | 2.5.20-1_1 |
sh-utils | 2.0.12-3_1 |
slang | 1.4.5-11_1 |
slang-devel | 1.4.5-11_1 |
strace | 4.4.93-1_1 |
sysklogd | 1.4.1-10_1 |
SysVinit | 2.84-5_1 |
tar | 1.13.25-8_1 |
tcp_wrappers | 7.6-23_1 |
telnet | 0.17-23_1 |
telnet-server | 0.17-23_1 |
termcap | 11.0.1-13_1 |
textutils | 2.0.21-5_1 |
tftp | 0.29-3a_1 |
tftp-server | 0.29-3a_1 |
thttpd | 2.23beta1-1 |
u-boot | 0.3.1-1 |
util-linux | 2.11y-2_1 |
vim-common | 6.1-29a_1 |
vim-minimal | 6.1-29a_1 |
wireless-tools | 25-1_1 |
wu-ftpd | 2.6.1-1 |
xinetd | 2.3.11-1.9.0_1 |
zlib | 1.1.4-4_1 |
zlib-devel | 1.1.4-4_1 |
Note: Not all packages will be installed automatically; for example the
boa
and thttpd
web servers are
mutually exclusive - you will have to remove one package before you
can (manually) install the other one.
In this section, you
will find instructions on how to build the ELDK
from scratch, using the pristine package sources available on the
Internet, and patches, spec files, and build scripts provided on the
ELDK source CD-ROM.
1.9.1. ELDK Build Process Overview
The ELDK uses
YellowDog 3.0 Linux distribution as a source code
reference. Any modifications to YellowDog's sources the ELDK has
introduced are in the form of patches applied by the RPM tool while
building the packages. Also, the ELDK uses modified spec files for
its RPM packages. So, the sources of almost every ELDK package
consist of the following parts:
- YellowDog pristine sources or
- ELDK source tarball,
- ELDK patches,
- ELDK spec file.
The YellowDog pristine sources may be obtained from the Internet, see
ftp://ftp.yellowdoglinux.com/pub/yellowdog/yellowdog-3.0/en/os/SRPMS/.
The ELDK patches and spec files are available on the ELDK source
CD-ROM and from the DENX anonymous CVS server. To access this CVS server
please use the following command to log on:
cvs -d :pserver:anonymous@www.denx.de:/cvsroot login
When prompted for the "CVS password:" just press the return key (empty password).
Please use the following commands to check out a copy of one of the modules:
cvs -z6 -d :pserver:anonymous@www.denx.de:/cvsroot co -P module
The following ELDK modules are available:
Module Name | Contents |
eldk_tarballs | Source tarballs |
eldk_build | Build tools, patches, and spec files |
It must be noted that some of the packages which are included in the
ELDK are not included in YellowDog. Examples of such packages are
busybox
, microwindows
, and wu-ftpd
. For these
packages tarballs are provided on the DENX anonymous CVS server.
To facilitate building of the ELDK, a build infrastructure has been
developed. The infrastructure is composed of the following components:
-
ELDK_BUILD
script
-
build.sh
script
-
cpkgs.lst
file
-
tpkgs.lst
file
-
SRPMS.lst
file
-
tarballs.lst
file
The ELDK_BUILD
script is the main script of the
ELDK build procedure. It is the tool that you would normally use to
build the ELDK from scratch. In the simplest case, the script may be
invoked without arguments, and it will perform all necessary steps to
build the ELDK in a fully automated way. You may pass two optional
arguments to the ELDK_BUILD
script:
-d <arch> | target architecture: "ppc", "arm" or "mips", defaults to "ppc". |
-n <build_name> | an identification string for the build. Defaults to the value based on the build architecture and current date, and has the following format: <arch>-YYYY-MM-DD |
build.sh
is a supplementary script that is called
by ELDK_BUILD
to accomplish certain steps of the
build. Refer to section 1.9.3. build.sh Usage below for more
details.
The cpkgs.lst and tpkgs.lst
files are read by build.sh
and must contain lines
describing sub-steps of the eldt and
trg build procedure steps. Essentially, the
files contain the list of the ELDT and target packages to be included
in the ELDK. The SRPMS.lst file contains the
list of the YellowDog source RPM packages used during the ELDK build.
The tarballs.lst file contains the list of
source tarballs of the packages that are included in the ELDK but are
not present in YellowDog 3.0.
For the ELDK_BUILD
script to work correctly, it
must be invoked from a certain build environment created on the host
system. The build environment can be either checked out from the DENX
CVS (see section 1.9.2. Setting Up ELDK Build Environment below for details) or copied
from the ELDK build environment CD-ROM.
To be more specific, the following diagram outlines the build
environment needed for correct operation of the
ELDK_BUILD
script:
<some_directory>/
build/cross_rpms/<package_name>/SPECS/...
SOURCES/...
target_rpms/<package_name>/SPECS/...
SOURCES/...
install/install.c
Makefile
misc/ELDK_MAKEDEV
ELDK_FIXOWNER
README.html
cpkgs.lst
tpkgs.lst
build.sh
ELDK_BUILD
SRPMS.lst
tarballs.lst
tarballs/....
SRPMS/....
In subdirectories of the cross_rpms and target_rpms
directories, the sources and RPM spec files of,
respectively, the ELDT and target packages are
stored. The install
subdirectory contains the sources of the installation utility which
will be built and placed in the root of the ISO image.
tarballs directory contains the source
tarballs of the packages that are included in the ELDK but are not
present in YellowDog 3.0.
The SRPMS directory may contain the source RPM packages of YellowDog
3.0. If some (or all) of the YellowDog SRPMs needed for the build are
missing in the directory, the ELDK_BUILD
script
will download the source RPMs automatically from the Internet.
The ELDK build environment CD-ROM provides a ready-to-use ELDK build
environment. Please refer to section
1.9.2. Setting Up ELDK Build Environment
below for detailed instructions on setting up the build environment.
The ELDK_BUILD
script examines the contents of the
ELDK_PREFIX
environment variable to determine the
root directory of the ELDK build environment. If the variable is not
set when the script is invoked, it is assumed that the root directory
of the ELDK build environment is /opt/eldk. To build the ELDK in the
example directory layout given above, you must set and export the
ELDK_PREFIX
variable <some_directory> prior to invoking
ELDK_BUILD
.
After all the build steps are complete, the following subdirectories
are created in the ELDK build environment:
build/<build_name>/work/ - full ELDK environment
build/<build_name>/logs/ - build procedure log files
build/<build_name>/results/b_cdrom/ - binary cdrom tree, ready for mkisofs
results/s_cdrom/ - source cdrom tree, ready for mkisofs
On Linux hosts, the binary and source ISO images are created
automatically by the ELDK_BUILD
script and placed
in the results directory. On
Solaris hosts, creating the ISO images is a manual step. Use the
contents of the b_cdrom and
s_cdrom directories for the
contents of the ISO images.
For your convenience,
the ELDK build environment CD-ROM provides full
ELDK build environment. All you need to do is copy the contents of
the CD-ROM to an empty directory on your host system. Assuming the
ELDK build environment CD-ROM is mounted at /mnt/cdrom,
and the empty directory
where you want to create the build environment is named
/opt/eldk, use the following
commands to create the build environment:
bash$ cd /opt/eldk
bash$ cp -r /mnt/cdrom/* .
These commands will create the directory structure as described in
section 1.9.1. ELDK Build Process Overview above.
All necessary scripts and ELDK specific source files will be placed in the
build subdirectory, and the required
tarballs can be found in the
tarballs subdirectory. In the
SRPMS subdirectory, you will find all
the YellowDog 3.0 SRPMS needed to build the ELDK.
Alternatively, you can obtain the ELDK build environment from the
DENX anonymous CVS server. Two modules are provided for check out:
eldk_build and
eldk_tarballs. The first one contains the files
for the build subdirectory in
the build environment, and the second one contains source tarballs of
the packages that are included in the ELDK but are not present in
YellowDog 3.0. To create the ELDK build environment from the DENX CVS
server, use the following commands (the example below assumes that
the root directory of the build environment is
/opt/eldk):
bash$ cd /opt/eldk
bash$ cvs -d :pserver:anonymous@www.denx.de:/cvsroot login
bash$ cvs -z6 -d :pserver:anonymous@www.denx.de:/cvsroot co -P eldk_build
bash$ cvs -z6 -d :pserver:anonymous@www.denx.de:/cvsroot co -P eldk_tarballs
After the eldk_build and
eldk_tarballs modules have been checked out, the
only remaining piece that is needed for the build is the YellowDog
3.0 source RPM packages, which will, if required, be automatically
downloaded by the ELDK_BUILD
script.
If you wish
to perform only a part of the ELDK build procedure, for
instance to re-build or update a certain package, it may sometimes be
convenient to invoke the build.sh
script manually,
without the aid of the ELDK_BUILD
script. Please
note, however, that this approach is in general discouraged.
The whole build procedure is logically divided into six steps, and
the build.sh
must be told which of the build steps
to perform. The build steps are defined as follows:
- rpm - build RPM
- eldt - build ELDT packages
- seldt - save ELDT SRPM packages to create a source ISO image later on
- trg - build target packages
- biso - prepare binary ISO image
- siso - prepare source ISO image
Further, the eldt and trg
build steps are devided into sub-steps, as defined in the
cpkgs.lst and tpckgs.lst
files (see below for details). You may specify which sub-steps of the
build step are to be performed.
The formal syntax for the usage of build.sh
is as follows:
bash$ ./build.sh [-a <arch>] [-n <name>] [-p <prefix>] [-r <result>] \
[-w <work>] <step_name> [<sub_step_number>]
-a <arch> | target architecture: "ppc", "arm" or "mips", defaults to "ppc". |
-n <build_name> | an identification string for the build. It is used as a name for some directories created during the build. You may use for example the current date as the build name. |
-p <prefix> | is the name of the directory that containsthe build environment. Refer to build overview above for description of the build envrionment. |
-r <result> | is the name of the directory where the resulting RPMs and SRPMs created on this step will be placed. |
-w <work> | is the name of the directory where the build is performed. |
<stepname> | is the name of the build step that is to be performed. Refer to the list of the build procedure steps above. |
<sub_step_number> | is an optional parameter which identifies sub-steps of the step which are to be performed. This is useful when you want to re-build only some specific packages. The numbers are defined in the cpkgs.lst and tpkgs.lst files discussed below. You can specify a range of numbers here. For instance, "2 5" means do steps from 2 to 5, while simply "2" means do all steps starting at 2. |
Please note that you must never use build.sh
to
build the ELDK from scratch. For build.sh
to work
correctly, the script must be invoked from the build environment
after a successful build using the ELDK_BUILD
script. A possible scenario of build.sh
usage is
such that you have a build environment with results of a build
performed using the ELDK_BUILD
script and want to
re-build certain ELDT and target packages, for instance, because you
have updated sources of a package or added a new package to the
build.
When building the target packages (during the
trg buildstep), build.sh
examines the contents of the
TARGET_CPU_FAMILY_LIST
environment variable, which
may contain a list indicating which target CPU variants the packages
must be built for.
Possible CPU variants are 8xx, 82xx, 4xx, 7xx, and 74xx.
For example, the command below rebuilds
the target RPM listed in the tpckgs.lst file
under the number of 47 (see section 1.9.4. Format of the cpkgs.lst and tpkgs.lst Files for
description of the tpckgs.lst and
cpkgs.lst files), for the 8xx and 82xx CPUs:
bash$ TARGET_CPU_FAMILY_LIST="82xx 8xx" \
> /opt/eldk/build.sh -a ppc \
> -n 2003-04-06 \
> -p /opt/eldk/build/ppc-2003-04-06 \
> -r /opt/eldk/build/ppc-2003-04-06/results \
> -w /opt/eldk/build/ppc-2003-04-06/work \
> trg 47 47
Note: If you are going to invoke build.sh
to re-build a
package that has already been build in the build environment by the
ELDK_BUILD
script, then you must first manually
uninstall the package from ELDK installation created by the build
procedure under the work
directory of the build environment.
Note: It is recommended that you use the build.sh
script
only at the final stage of adding/updating a package to the ELDK. For
debugging purposes, it is much more convenient and efficient to build
both ELDT and target packages using a working ELDK installation, as
described in the sections 1.7.2. Rebuilding Target Packages
and 1.7.3. Rebuilding ELDT Packages above.
Each line of these files has the following format:
<sub_step_number> <package_name> <spec_file_name> \
<binary_package_name> <package_version>
The ELDK source CD-ROM contains the cpkgs.lst
and tpkgs.lst files used to build this version
of the ELDK distribution. Use them as reference if you want to
include any additional packages into the ELDK, or remove unneeded
packages.
To add a package to the ELDK you must add a line to either the
cpkgs.lst file, if you are adding a ELDT
package, or to the tpkgs.lst file, if it is a
target package. Keep in mind that the relative positions of packages
in the cpkgs.lst and
tpkgs.lst files (the sub-step numbers) are very
important. The build procedure builds the packages sequentially as
defined in the *.lst files and installs the
packages in the "work" environment as they are built. This
implies that if a package depends on other packages, those packages
must be specified earlier (with smaller sub-step numbers) in the
*.lst files.