|
DENX . DULG . ELDKRebuilding
|
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.
3.10.1. ELDK Build Process Overview
The ELDK uses the
Fedora 7 Linux distribution as source code
reference. Any modifications to Fedora'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:
- Fedora pristine sources or
- ELDK source tarball,
- ELDK patches,
- ELDK spec file.
The Fedora pristine sources may be obtained from the Internet, see
http://download.fedora.redhat.com/pub/fedora/linux/core.
The ELDK patches and spec files are available on the ELDK source
CD-ROM and from the DENX GIT repositories. Also, for convenience,
the pristine Fedora sources are available here, too.
Please use the following commands to check out a copy of one of the modules:
git-clone git://www.denx.de/git/eldk/module
The following ELDK modules are available:
| Module Name | Contents |
|---|
| tarballs | Source tarballs |
| build | Build tools, patches, and spec files |
| SRPMS | Fedora 7 sources |
Then you may switch to a specific release of the ELDK using the "git-checkout" command; for example, to get the files for
ELDK release 4.1, please do the following from the module directory:
git-checkout ELDK_4_2
It must be noted that some of the packages which are included in the
ELDK are not included in Fedora. Examples of such packages are
appWeb, microwindows, and wu-ftpd. For these
packages tarballs are provided in the DENX GIT repository.
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 the following optional
arguments to the ELDK_BUILD script:
-a <arch> | target architecture: "arm", "ppc" or "ppc64", 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 |
-v <version> | ELDK version string |
-u | build the uClibc-based ELDK version (on the platforms and versions where this is available). |
-p <builddir> | Optional build directory. By default, build will place the work files and results in the current directory. |
Warning: The ELDK build scripts rely on standard behaviour of the RPM tool.
Make sure you don't use non-standard settings in your personal ~/.rpmmacros file that
might cause conflicts.
build.sh is a supplementary script that is called
by ELDK_BUILD to accomplish certain steps of the
build. Refer to section 3.10.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 Fedora 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 Fedora 7.
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
GIT repository (see section 3.10.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/....
SRPMS-updates/....
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 Fedora 7.
The SRPMS and SRPMS-updates directories may contain the source RPM packages of Fedora
7. The ELDK_BUILD script looks for a package in the SRPMS directory and then, if the package is
not found, in the SRPMS-updates directory. If some (or all) of the Fedora SRPMs needed for
the build are missing in the directories, 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
3.10.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
results/d_cdrom/ - debuginfo 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 3.10.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 Fedora 7 SRPMS needed to build the ELDK.
Alternatively, you can obtain the ELDK build environment from the
DENX GIT repository. Two modules are provided for check out:
build and
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
Fedora 7. To create the ELDK build environment from the DENX GIT
repository, use the following commands (the example below assumes that
the root directory of the build environment is
/opt/eldk):
bash$ cd /opt/eldk
bash$ git-clone git://www.denx.de/git/eldk/build
bash$ git-clone git://www.denx.de/git/eldk/tarballs
bash$ git-clone git://www.denx.de/git/eldk/SRPMS
Note:
To allow to install the ELDK on as many as possible Linux
distributions (including old systems), we use a Red Hat 7.3 host
system for building. Also, Fedora Core 5 is known to work as a build
environment. Other, especially more recent Linux distributions, will
most likely have problems. We therefor provide a Red Hat 7.3 based
root file system image than can run in some virtualization
environment (like qemu etc.). Here is an application note with
detailed instructions:
http://www.denx.de/wiki/DULG/AN2009_02_EldkReleaseBuildEnvironment
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 the file tree to create the binary ISO image
- siso - prepare the file tree to create the source ISO image
- diso - prepare the file tree to create the debuginfo ISO image
Further, the eldt and trg
build steps are devided into sub-steps, as defined in the
cpkgs.lst and tpkgs.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", "ppc64", "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 contains the build environment. Refer to build overview above for description of the build environment. |
-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 4xx, 4xxFP, 6xx, 74xx, 8xx, 85xx and ppc64.
For example, the command below rebuilds
the target RPM listed in the tpckgs.lst file
under the number of 47 (see section 3.10.4. Format of the cpkgs.lst and tpkgs.lst Files for
description of the tpckgs.lst and
cpkgs.lst files), for the 8xx and 85xx CPUs:
bash$ TARGET_CPU_FAMILY_LIST="8xx 85xx" \
> /opt/eldk/build.sh -a ppc \
> -n 2007-01-19 \
> -p /opt/eldk/build/ppc-2007-01-19 \
> -r /opt/eldk/build/ppc-2007-01-19/results \
> -w /opt/eldk/build/ppc-2007-01-19/work \
> trg 47 47
Note: If you are going to invoke build.sh to re-build a
package that has already been built 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 3.8.2. Rebuilding Target Packages
and 3.8.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.
Note: For cpkgs.lst, the package_version may be replaced
by the special keyword "RHAUX". Such packages are used as auxiliary when building
ELDK 4.2 on non-Fedora hosts. These packages will be built and used during the
build process, but will not be put into the ELDK 4.2 distribution ISO images.
Copyright © 2002-2021 by DENX Software Engineering