Skip to main content.
Navigation:
DENX
>
DULG
>
ELDKRebuilding
Translations:
Edit
|
Attach
|
Raw
|
Ref-By
|
Printable
|
More
DULG
Sections of this site:
DENX Home
|
DULG
|
ELDK-5
|
Know
|
Training
|
U-Boot
|
U-Bootdoc
Topics
DULG Home
BoardSelect
Manual
FAQ
Application Notes
Changes
Index
List of pages in DULG
Search
%SECTION0{name=ELDKRebuildFromScratch}% Rebuilding the ELDK from Scratch #EldkRebuildFromScratch 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. %SECTION1{name=ELDKBuildOverview}% ELDK Build Process Overview #BuildOverview 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: <pre> git-clone git://www.denx.de/git/eldk/<i>module</i> </pre> The following ELDK modules are available: %TABLE{ headeralign="left, left" cellpadding="4" databg="#FFFFFF" }% | *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 <i>module</i> directory: <pre> git-checkout ELDK_4_2 </pre> 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: %TABLE{ tableborder="0" headerrows="0" cellspacing="5" databg="#FFFFFF" }% | =-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. | %X% 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 %REF{type=Section,name=ELDKBuildScript}% 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 %REF{type=Section,name=ELDKBuildSetup}% 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: <verbatim> <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/.... </verbatim> 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 %REF{type=Section,name=ELDKBuildSetup}% 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: <verbatim> 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 </verbatim> 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. #BuildSetup %SECTION1{name=ELDKBuildSetup}% Setting Up ELDK Build Environment 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: <verbatim> bash$ cd /opt/eldk bash$ cp -r /mnt/cdrom/* . </verbatim> These commands will create the directory structure as described in section %REF{type=Section,name=ELDKBuildOverview}% 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_): <verbatim> 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 </verbatim> %X% *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 #BuildScript %SECTION1{name=ELDKBuildScript}% build.sh Usage 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: <verbatim> bash$ ./build.sh [-a <arch>] [-n <name>] [-p <prefix>] [-r <result>] \ [-w <work>] <step_name> [<sub_step_number>] </verbatim> %TABLE{ tableborder="0" headerrows="0" cellspacing="5" databg="#FFFFFF" valign="top" }% | =-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 [[#BuildOverview][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. | %X% 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 %IF{ "%ARCHITECTURE%" eq "powerpc" }% _4xx_, _4xxFP_, _6xx_, _74xx_, _8xx_, _85xx_ and _ppc64_. %ENDIF% %IF{ "%ARCHITECTURE%" eq "arm" }% _arm_. %ENDIF% %IF{ "%ARCHITECTURE%" eq "mips" }% _4KC_ and _4KCle_. %ENDIF% For example, the command below rebuilds the target RPM listed in the _tpckgs.lst_ file under the number of 47 (see section %REF{type=Section,name=ELDKBuildFiles}% for description of the _tpckgs.lst_ and _cpkgs.lst_ files), for the %IF{ "%ARCHITECTURE%" eq "powerpc" }% _8xx_ and _85xx_ CPUs: %ENDIF% %IF{ "%ARCHITECTURE%" eq "arm" }% _arm_ CPU: %ENDIF% %IF{ "%ARCHITECTURE%" eq "mips" }% _4KC_ CPU: %ENDIF% %IF{ "%ARCHITECTURE%" eq "powerpc" }% <verbatim> 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 </verbatim> %ENDIF% %IF{ "%ARCHITECTURE%" eq "arm" }% <verbatim> bash$ TARGET_CPU_FAMILY_LIST="arm" \ > /opt/eldk/build.sh -a arm \ > -n 2007-01-21 \ > -p /opt/eldk/build/arm-2007-01-21 \ > -r /opt/eldk/build/arm-2007-01-21/results \ > -w /opt/eldk/build/arm-2007-01-21/work \ > trg 47 47 </verbatim> %ENDIF% %IF{ "%ARCHITECTURE%" eq "mips" }% <verbatim> bash$ TARGET_CPU_FAMILY_LIST="mips" \ > /opt/eldk/build.sh -a mips \ > -n 2007-01-21 \ > -p /opt/eldk/build/mips-2007-01-21 \ > -r /opt/eldk/build/mips-2007-01-21/results \ > -w /opt/eldk/build/mips-2007-01-21/work \ > trg 47 47 </verbatim> %ENDIF% %BLUE%Note:%ENDCOLOR% 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. %BLUE%Note:%ENDCOLOR% 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 %REF{type=Section,topic=ELDKRebuildingComponents,name=ELDKRebuildTargetRpm}% and %REF{type=Section,topic=ELDKRebuildingComponents,name=ELDKRebuildToolRpm}% above. #BuildFiles %SECTION1{name=ELDKBuildFiles}% Format of the cpkgs.lst and tpkgs.lst Files Each line of these files has the following format: <verbatim> <sub_step_number> <package_name> <spec_file_name> \ <binary_package_name> <package_version> </verbatim> 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. %BLUE%Note:%ENDCOLOR% 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.
3.9. ELDK Packages
1. Abstract
3.11. Notes for Solaris 2.x Host Environment
Prev
Home
Next