mirror of
https://git.rtems.org/rtems-source-builder
synced 2024-10-09 07:15:10 +08:00
eef48f9f74
A user asked for the documentation to be move higher in the source tree so it is easier to find.
1402 lines
55 KiB
Plaintext
1402 lines
55 KiB
Plaintext
RTEMS Source Builder
|
|
====================
|
|
:doctype: book
|
|
:toc2:
|
|
:toclevels: 5
|
|
:icons:
|
|
:numbered:
|
|
|
|
image:images/rtemswhitebg.jpg["RTEMS",width="30%"]
|
|
|
|
Chris Johns <chrisj@rtems.org>
|
|
1.0, February 2013
|
|
|
|
RTEMS Tools From Source
|
|
-----------------------
|
|
|
|
The RTEMS Source Builder is a tool to aid building packages from source. It is
|
|
not a package manager. It helps consolidate the details you need to know to
|
|
build a package from source in a controlled and verifiable way. The tool is
|
|
mainly aimed at developers of software who use tool sets for embedded type
|
|
development. Embedded development typically uses cross-compiling tool chains,
|
|
debuggers, and debugging aids. Together we call these a tool set. The RTEMS
|
|
Source Builder is not limited to this role but designed to fit with-in this
|
|
specific niche. It can be used outside of the RTEMS project and we welcome this
|
|
happening in other open source or commercial projects.
|
|
|
|
The RTEMS Source Builder is typically used to build a set of tools or a _build
|
|
set_. A _build set_ is a collection of packages and a package is a specific
|
|
tool, for example gcc or gdb. The RTEMS Source Builder attempts to support any
|
|
host environment that runs Python and you can build the package on. It is not
|
|
some sort of magic that can take any piece of source code and make it
|
|
build. Someone at some point in time has figured out how to build that package
|
|
from source and taught this tool. The RTEMS Source Builder has been tested on:
|
|
|
|
. FreeBSD
|
|
. MacOS (Mountain Lion)
|
|
. Ubuntu
|
|
. Centos
|
|
. Fedora
|
|
. Raspbian
|
|
|
|
Windows support is being added how-ever there are issues with the Python
|
|
threading used in the RTEMS Source Builder and the MinGW project's MSYS process
|
|
handling of make.
|
|
|
|
The RTEMS Source Builder has two types configuration data. The first is the
|
|
_build set_. A _build set_ describes a collection of packages that define a set
|
|
of tools you would use when developing software for RTEMS. For example the
|
|
basic GNU tool set is binutils, gcc, and gdb and is the typical base suite of
|
|
tools you need for an embedded cross-development type project. The second type
|
|
of configuration data is the configuration files and they define how a package
|
|
is built. Configuration files are scripts based on the RPM spec file format
|
|
and detail the steps needed to build a package. The steps are 'preparation',
|
|
'building', and 'installing'. The script support macros, shell expansion,
|
|
logic, includes and many more featured need to build packages.
|
|
|
|
The RTEMS Source Builder does not interact with any host package management
|
|
system. There is no automatic dependence checking between various packages you
|
|
build or packages or software your host system may have installed. We assume
|
|
the build sets and configuration files you are using have been created by
|
|
developers who do.
|
|
|
|
Quick Start
|
|
-----------
|
|
|
|
The quick start will show you how to build a set of RTEMS tools for a supported
|
|
architecture.
|
|
|
|
There is no need to become root or the administrator and we recommend you avoid
|
|
doing this. You can build and install the tools anywhere on the host's file
|
|
system you as a standard user have read and write access. I recommend you use
|
|
your home directory and work under the directory +~/development+. The
|
|
examples shown here will do this.
|
|
|
|
You can use the build _prefix_ to install and maintain different versions of
|
|
the tools. Doing this lets you try a new set of tools while not touching your
|
|
proven working production set of tools. Once you have proven the new tools are
|
|
working rebuild with the _producion_ prefix switching your development to them.
|
|
|
|
I also suggest you keep your environment to the bare minimum, particularly the
|
|
path variable. Using environment variables has been proven over the years to be
|
|
difficult to manage in production systems.
|
|
|
|
Setup
|
|
~~~~~
|
|
|
|
Setup a development work space:
|
|
|
|
-------------------------------------------------------------
|
|
$ cd
|
|
$ mkdir -p development/rtems/src
|
|
$ cd development/rtems/src
|
|
-------------------------------------------------------------
|
|
|
|
The RTEMS Source Builder is distributed as source. It is Python code so all you
|
|
need to do is head over to the RTEMS GIT repository and clone the code directly
|
|
from git:
|
|
|
|
-------------------------------------------------------------
|
|
$ git clone git://git.rtems.org/chrisj/rtems-source-builder.git
|
|
$ cd rtems-source-builder
|
|
-------------------------------------------------------------
|
|
|
|
Checking
|
|
~~~~~~~~
|
|
|
|
The next step is to check if your host is set up correctly. The RTEMS Source
|
|
Builder provides a tool to help:
|
|
|
|
-------------------------------------------------------------
|
|
$ source-builder/sb-check
|
|
warning: exe: absolute exe found in path: (__objcopy) /usr/local/bin/objcopy <1>
|
|
warning: exe: absolute exe found in path: (__objdump) /usr/local/bin/objdump
|
|
error: exe: not found: (_xz) /usr/local/bin/xz <2>
|
|
RTEMS Source Builder environent is not correctly set up
|
|
$ source-builder/sb-check
|
|
RTEMS Source Builder environent is ok <3>
|
|
-------------------------------------------------------------
|
|
|
|
<1> A tool is in the environment path but does not match the shown path.
|
|
<2> The executable 'xz' is not found.
|
|
<3> The host's environment is set up correct.
|
|
|
|
The checking tool will output a list of executables not found if problems are
|
|
detected. Locate those executables and install them. You may also be given a
|
|
list of warnings about executables not in the expected location how-ever the
|
|
executable was located somewhere in your environment's path. You will need to
|
|
check each tool to determine if this is an issue. An executable not in the
|
|
standard location may indicate it is not the host operating system's standard
|
|
tool. It maybe ok or it could be buggy.
|
|
|
|
The <<_host_setups,Host Setups>> section lists packages you should install for
|
|
common host operating systems. It maybe worth checking if you have those
|
|
installed.
|
|
|
|
Build Sets
|
|
~~~~~~~~~~
|
|
|
|
The RTEMS tools can be built within the RTEMS Source Builder's source tree. We
|
|
recommend you do this so lets change into the RTEMS directory in the RTEMS
|
|
Source Builder package:
|
|
|
|
-------------------------------------------------------------
|
|
$ cd rtems
|
|
-------------------------------------------------------------
|
|
|
|
If you are unsure how to specify the build set for the architecure you wish to
|
|
build ask the tool:
|
|
|
|
-------------------------------------------------------------
|
|
$ ../source-builder/sb-set-builder --list-bsets <1>
|
|
RTEMS Source Builder - Set Builder, v0.1
|
|
Examining: config <2>
|
|
Examining: ../source-builder/config <2>
|
|
4.11/rtems-all.bset <3>
|
|
4.11/rtems-arm.bset <4>
|
|
4.11/rtems-avr.bset
|
|
4.11/rtems-bfin.bset
|
|
4.11/rtems-h8300.bset
|
|
4.11/rtems-m32c.bset
|
|
4.11/rtems-m32r.bset
|
|
4.11/rtems-m68k.bset
|
|
4.11/rtems-microblaze.bset
|
|
4.11/rtems-mips.bset
|
|
4.11/rtems-moxie.bset
|
|
4.11/rtems-nios2.bset
|
|
4.11/rtems-powerpc.bset
|
|
4.11/rtems-sh.bset
|
|
4.11/rtems-sparc.bset
|
|
gnu-tools-4.6.bset
|
|
rtems-4.11-base.bset
|
|
unstable/4.11/rtems-all.bset <5>
|
|
unstable/4.11/rtems-arm.bset
|
|
unstable/4.11/rtems-avr.bset
|
|
unstable/4.11/rtems-bfin.bset
|
|
unstable/4.11/rtems-h8300.bset
|
|
unstable/4.11/rtems-m32c.bset
|
|
unstable/4.11/rtems-m32r.bset
|
|
unstable/4.11/rtems-m68k.bset
|
|
unstable/4.11/rtems-microblaze.bset
|
|
unstable/4.11/rtems-mips.bset
|
|
unstable/4.11/rtems-moxie.bset
|
|
unstable/4.11/rtems-powerpc.bset
|
|
unstable/4.11/rtems-sh.bset
|
|
unstable/4.11/rtems-sparc.bset
|
|
-------------------------------------------------------------
|
|
<1> Only option needed is +--list-bsets+
|
|
<2> The paths inspected. See <<X1,+_configdir+>> variable.
|
|
<3> Build all the architectures.
|
|
<4> The build set for the ARM architecture.
|
|
<5> Unstable tool sets are used by RTEMS developers to test new tool sets. You
|
|
are welcome to try them but you must remember they are unstable, can change
|
|
at point in time and your application may not work. If you have an issue
|
|
with a production tool it may pay to try the unstable tool to see if it has
|
|
been resolved.
|
|
|
|
Building
|
|
~~~~~~~~
|
|
|
|
In this quick start I will build an SPARC tool set.
|
|
|
|
-------------------------------------------------------------
|
|
$ ../source-builder/sb-set-builder --log=l-sparc.txt <1> \
|
|
--prefix=$HOME/development/rtems/4.11 <2> 4.11/rtems-sparc <3>
|
|
Source Builder - Set Builder, v0.1
|
|
Build Set: 4.11/rtems-sparc
|
|
config: expat-2.1.0-1.cfg <4>
|
|
package: expat-2.1.0-x86_64-freebsd9.1-1
|
|
building: expat-2.1.0-x86_64-freebsd9.1-1
|
|
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11 <5>
|
|
config: tools/rtems-binutils-2.22-1.cfg <6>
|
|
package: sparc-rtems4.11-binutils-2.22-1
|
|
building: sparc-rtems4.11-binutils-2.22-1
|
|
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
|
|
config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg <7>
|
|
package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
|
|
config: tools/rtems-gdb-7.5.1-1.cfg <8>
|
|
package: sparc-rtems4.11-gdb-7.5.1-1
|
|
building: sparc-rtems4.11-gdb-7.5.1-1
|
|
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
|
|
cleaning: expat-2.1.0-x86_64-freebsd9.1-1 <9>
|
|
cleaning: sparc-rtems4.11-binutils-2.22-1
|
|
cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
cleaning: sparc-rtems4.11-gdb-7.5.1-1
|
|
Build Set: Time 0:13:43.616383 <10>
|
|
-------------------------------------------------------------
|
|
|
|
<1> Providing a log file redirects the build output into a file. Logging the
|
|
build output provides a simple way to report problems.
|
|
<2> The prefix is the location on your file system the tools are installed
|
|
into. Provide a prefix to a location you have read and write access. You
|
|
can use the prefix to install different version or builds of tools. Just
|
|
use the path to the tools you want to use when building RTEMS.
|
|
<3> The build set. This is the SPARC build set.
|
|
<4> The SPARC build set build the expat library that is used in GDB. This is the
|
|
expat configuration.
|
|
<5> Installing the expat package to the install prefix.
|
|
<6> The binutils build configuration.
|
|
<7> The GCC and Newlib build configuration.
|
|
<8> The GDB build configuration.
|
|
<9> All the packages built are cleaned at the end. If the build fails all the
|
|
needed files are present. You may have to clean up by deleting the build
|
|
directory.
|
|
<10> The time to build the package. This lets you see how different host
|
|
hardware or configurations perform.
|
|
|
|
Your SPARC RTEMS 4.11 tool set will be installed and ready to build RTEMS and
|
|
RTEMS applications. When the build runs you will notice the tool fetch the
|
|
source code from the internet. These files are cached in a directory called
|
|
+source+. If you run the build again the cached files are used.
|
|
|
|
-------------------------------------------------------------
|
|
$ ls $HOME/development/rtems/4.11
|
|
bin include lib libexec share sparc-rtems4.11
|
|
$ ls $HOME/development/rtems/4.11/bin
|
|
sparc-rtems4.11-addr2line sparc-rtems4.11-cpp
|
|
sparc-rtems4.11-gcc-ar sparc-rtems4.11-gprof
|
|
sparc-rtems4.11-objdump sparc-rtems4.11-size
|
|
sparc-rtems4.11-ar sparc-rtems4.11-elfedit
|
|
sparc-rtems4.11-gcc-nm sparc-rtems4.11-ld
|
|
sparc-rtems4.11-ranlib sparc-rtems4.11-strings
|
|
sparc-rtems4.11-as sparc-rtems4.11-g++
|
|
sparc-rtems4.11-gcc-ranlib sparc-rtems4.11-ld.bfd
|
|
sparc-rtems4.11-readelf sparc-rtems4.11-strip
|
|
sparc-rtems4.11-c++ sparc-rtems4.11-gcc
|
|
sparc-rtems4.11-gcov sparc-rtems4.11-nm
|
|
sparc-rtems4.11-run xmlwf
|
|
sparc-rtems4.11-c++filt sparc-rtems4.11-gcc-4.7.2
|
|
sparc-rtems4.11-gdb sparc-rtems4.11-objcopy
|
|
sparc-rtems4.11-sis
|
|
$ $HOME/development/rtems/4.11/bin/sparc-rtems4.11-gcc -v
|
|
Using built-in specs.
|
|
COLLECT_GCC=/home/chris/development/rtems/4.11/bin/sparc-rtems4.11-gcc
|
|
COLLECT_LTO_WRAPPER=/usr/home/chris/development/rtems/4.11/bin/../ \
|
|
libexec/gcc/sparc-rtems4.11/4.7.2/lto-wrapper
|
|
Target: sparc-rtems4.11
|
|
Configured with: ../gcc-4.7.2/configure
|
|
--prefix=/home/chris/development/rtems/4.11
|
|
--bindir=/home/chris/development/rtems/4.11/bin
|
|
--exec_prefix=/home/chris/development/rtems/4.11
|
|
--includedir=/home/chris/development/rtems/4.11/include
|
|
--libdir=/home/chris/development/rtems/4.11/lib
|
|
--libexecdir=/home/chris/development/rtems/4.11/libexec
|
|
--mandir=/home/chris/development/rtems/4.11/share/man
|
|
--infodir=/home/chris/development/rtems/4.11/share/info
|
|
--datadir=/home/chris/development/rtems/4.11/share
|
|
--build=x86_64-freebsd9.1 --host=x86_64-freebsd9.1 --target=sparc-rtems4.11
|
|
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib
|
|
--with-system-zlib --disable-nls --without-included-gettext
|
|
--disable-win32-registry --enable-version-specific-runtime-libs --disable-lto
|
|
--enable-threads --enable-plugin --enable-newlib-io-c99-formats
|
|
--enable-newlib-iconv --enable-languages=c,c++
|
|
Thread model: rtems
|
|
gcc version 4.7.2 20120920 (RTEMS) (GCC)
|
|
-------------------------------------------------------------
|
|
|
|
Installing and Tar Files
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The RTEMS Source Builder can install the built packages directly and optionally it can
|
|
create a build set tar file or a tar file per package built. The normal and
|
|
default behaviour is to let the RTEMS Source Builder install the tools. The
|
|
source will be downloaded, built, installed and cleaned up.
|
|
|
|
The tar files are created with the full build prefix present. This can cause
|
|
problems if you are installing on a host you do not have super user or
|
|
administrator rights on if the prefix path references part you do not have
|
|
write access t0o. You can use the +--strip-components+ if you tar file has the
|
|
option to remove the parts you do not have write access too or you may need to
|
|
unpack the tar file somewhere and copy the file tree from the level you have
|
|
write access from. Embedding the full prefix path in the tar files lets you know
|
|
what the prefix is.
|
|
|
|
A build set tar file can created by adding +--bset-tar-file+ option to the
|
|
+sb-set-builder+ command.
|
|
|
|
-------------------------------------------------------------
|
|
$ ../source-builder/sb-set-builder --log=l-sparc.txt \
|
|
--prefix=$HOME/development/rtems/4.11 \
|
|
--bset-tar-file <1> 4.11/rtems-sparc
|
|
Source Builder - Set Builder, v0.1
|
|
Build Set: 4.11/rtems-sparc
|
|
config: expat-2.1.0-1.cfg
|
|
package: expat-2.1.0-x86_64-freebsd9.1-1
|
|
building: expat-2.1.0-x86_64-freebsd9.1-1
|
|
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11 <2>
|
|
config: tools/rtems-binutils-2.22-1.cfg
|
|
package: sparc-rtems4.11-binutils-2.22-1
|
|
building: sparc-rtems4.11-binutils-2.22-1
|
|
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
|
|
config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
|
|
package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
|
|
config: tools/rtems-gdb-7.5.1-1.cfg
|
|
package: sparc-rtems4.11-gdb-7.5.1-1
|
|
building: sparc-rtems4.11-gdb-7.5.1-1
|
|
installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
|
|
tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2 <3>
|
|
cleaning: expat-2.1.0-x86_64-freebsd9.1-1
|
|
cleaning: sparc-rtems4.11-binutils-2.22-1
|
|
cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
cleaning: sparc-rtems4.11-gdb-7.5.1-1
|
|
Build Set: Time 0:15:25.92873
|
|
-------------------------------------------------------------
|
|
|
|
<1> The option to create a build set tar file.
|
|
<2> The installation still happens.
|
|
<3> Creating the build set tar file.
|
|
|
|
You can also suppress installing the files using the +--no-install+ option to
|
|
the +sb-set-builder+.
|
|
|
|
-------------------------------------------------------------
|
|
$ ../source-builder/sb-set-builder --log=l-sparc.txt \
|
|
--prefix=$HOME/development/rtems/4.11 \
|
|
--bset-tar-file --no-install <1> 4.11/rtems-sparc
|
|
Source Builder - Set Builder, v0.1
|
|
Build Set: 4.11/rtems-sparc
|
|
config: expat-2.1.0-1.cfg
|
|
package: expat-2.1.0-x86_64-freebsd9.1-1
|
|
building: expat-2.1.0-x86_64-freebsd9.1-1
|
|
config: tools/rtems-binutils-2.22-1.cfg
|
|
package: sparc-rtems4.11-binutils-2.22-1
|
|
building: sparc-rtems4.11-binutils-2.22-1
|
|
config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
|
|
package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
config: tools/rtems-gdb-7.5.1-1.cfg
|
|
package: sparc-rtems4.11-gdb-7.5.1-1
|
|
building: sparc-rtems4.11-gdb-7.5.1-1
|
|
tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2 <2>
|
|
cleaning: expat-2.1.0-x86_64-freebsd9.1-1
|
|
cleaning: sparc-rtems4.11-binutils-2.22-1
|
|
cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
cleaning: sparc-rtems4.11-gdb-7.5.1-1
|
|
Build Set: Time 0:14:11.721274
|
|
$ ls tar
|
|
rtems-4.11-sparc-rtems4.11-1.tar.bz2
|
|
-------------------------------------------------------------
|
|
|
|
<1> The option to supressing installing the packages.
|
|
<2> Create the build set tar.
|
|
|
|
A package tar file can be created by adding the +--pkg-tar-files+ to the
|
|
+sb-set-builder+ command. This creates a tar file per package built in the
|
|
build set.
|
|
|
|
-------------------------------------------------------------
|
|
$ ../source-builder/sb-set-builder --log=l-sparc.txt \
|
|
--prefix=$HOME/development/rtems/4.11 \
|
|
--bset-tar-file --pkg-tar-files <1> --no-install 4.11/rtems-sparc
|
|
Source Builder - Set Builder, v0.1
|
|
Build Set: 4.11/rtems-sparc
|
|
config: expat-2.1.0-1.cfg
|
|
package: expat-2.1.0-x86_64-freebsd9.1-1
|
|
building: expat-2.1.0-x86_64-freebsd9.1-1
|
|
config: tools/rtems-binutils-2.22-1.cfg
|
|
package: sparc-rtems4.11-binutils-2.22-1
|
|
building: sparc-rtems4.11-binutils-2.22-1
|
|
config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
|
|
package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
config: tools/rtems-gdb-7.5.1-1.cfg
|
|
package: sparc-rtems4.11-gdb-7.5.1-1
|
|
building: sparc-rtems4.11-gdb-7.5.1-1
|
|
tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2
|
|
cleaning: expat-2.1.0-x86_64-freebsd9.1-1
|
|
cleaning: sparc-rtems4.11-binutils-2.22-1
|
|
cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
|
|
cleaning: sparc-rtems4.11-gdb-7.5.1-1
|
|
Build Set: Time 0:14:37.658460
|
|
$ ls tar
|
|
expat-2.1.0-x86_64-freebsd9.1-1.tar.bz2 sparc-rtems4.11-binutils-2.22-1.tar.bz2
|
|
sparc-rtems4.11-gdb-7.5.1-1.tar.bz2 <2> rtems-4.11-sparc-rtems4.11-1.tar.bz2 <3>
|
|
sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1.tar.bz2
|
|
-------------------------------------------------------------
|
|
|
|
<1> The option to create packages tar files.
|
|
<2> The GDB package tar file.
|
|
<3> The build set tar file. All the others in a single tar file.
|
|
|
|
Why Build from Source ?
|
|
-----------------------
|
|
|
|
The RTEMS Source Builder is not a replacement for the binary install systems
|
|
you have with commercial operating systems or open source operating system
|
|
distributions. Those products and distributions are critically important and
|
|
are the base that allows the Source Builder to work. The RTEMS Source Builder
|
|
sits somewhere between you manually entering the commands to build a tool set
|
|
and a tool such as +yum+ or +apt-get+ to install binary packages made
|
|
specifically for your host operating system. Building manually or installing a
|
|
binary package from a remote repository are valid and real alternatives while
|
|
the Source Builder is attempting to provide a specific service of repeatably
|
|
being able to build tool sets from source code.
|
|
|
|
If you are developing a system or product that has a long shelf life or is used
|
|
in a critical piece of infastructure that has a long life cycle being able to
|
|
build from source is important. It insulates the project from the fast ever
|
|
changing world of the host development machines. If your tool set is binary and
|
|
you have lost the ability to build it you have lost a degree of control and
|
|
flexibility open source gives you. Fast moving host environments are
|
|
fantastic. We have powerful multi-core computers with huge amounts of memory
|
|
and state of the art operating systems to run on them how-ever the product or
|
|
project you are part of may need to be maintained well past the life time of
|
|
these host. Being able to build from source an important and critical part of
|
|
this process because you can move to a newer host and create an equivalent tool
|
|
set.
|
|
|
|
Building from source provides you with control over the configuration of the
|
|
package you are building. If all or the most important dependent parts are
|
|
built from source you limit the exposure to host variations. For example the
|
|
GNU C compiler (gcc) currently uses a number of 3rd party libraries internally
|
|
(gmp, mpfr, etc). If your validated compiler generating code for your target
|
|
processor is dynamically linked against the host's version of these libraries
|
|
any change in the host's configuration may effect you. The changes the host's
|
|
package management system makes may be perfectly reasonible in relation to the
|
|
distribution being managed how-ever this may not extend to you and your
|
|
tools. Building your tools from source and controlling the specific version of
|
|
these dependent parts means you are not exposing yourself to unexpected and
|
|
often difficult to resolve problems. On the other side you need to make sure
|
|
your tools build and work with newer versions of the host operating
|
|
sytem. Given the stability of standards based libraries like 'libc' and ever
|
|
improving support for standard header file locations this task is becoming
|
|
easier.
|
|
|
|
The RTEMS Source Builder is designed to be audited and incorporated into a
|
|
project's verifcation and validation process. If your project is developing
|
|
critical applications that needs to be traced from source to executable code in
|
|
the target, you need to also consiser the tools and how to track them.
|
|
|
|
If your IT department maintains all your computers and you do not have suitable
|
|
rights to install binary packages, building from source lets you create your
|
|
own tool set that you install under your home directory. Avoiding installing
|
|
any extra packages as a super user is always helpful in maintaining a secure
|
|
computing environment.
|
|
|
|
Configuration
|
|
-------------
|
|
|
|
The RTEMS Source Builder has two types of configuration data:
|
|
|
|
. Build Sets
|
|
. Package Build Configurations
|
|
|
|
By default these files can be located in two separate directories and
|
|
searched. The first directory is +config+ in your current working directory
|
|
(+_topdir+) and the second is +config+ located in the base directory the RTEMS
|
|
Source Builder command you run (+_sbdir+). The RTEMS directory +rtems+ located
|
|
at the top of the RTEMS Source Builder source code is an example of a specific
|
|
build configuration directory. You cane create custom or private build
|
|
configurations and if you run the RTEMS Source Builder command from that
|
|
directory your configurations will be used.
|
|
|
|
[[X1]] The configuration search path is the macro variable and is reference as
|
|
+%\{_configdir\}+. It's default is defined as:
|
|
|
|
-------------------------------------------------------------
|
|
_configdir : dir optional %{_topdir}/config:%{_sbdir}/config <1>
|
|
-------------------------------------------------------------
|
|
|
|
<1> The +_topdir+ is the directory you run the command from and +_sbdir+ is
|
|
the location of the RTEMS Source Builder command.
|
|
|
|
Build set files have the file extension +.bset+ and the package build
|
|
configuration files have the file extension of +.cfg+. The +sb-set-builder+
|
|
command will search for _build sets_ and the +sb-builder+ commands works with
|
|
package build configuration files.
|
|
|
|
Both types of configuration files use the \'#' character as a comment
|
|
character. Anything after this character on the line is ignored. There is no
|
|
block comment.
|
|
|
|
Macros and Defaults
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
The RTEMS Source Builder uses a table of _macros_ called the _defaults_. The
|
|
values the _defaults_ are initialised to are dependent on your host. This lets
|
|
the Source Builder handle differences in the hosts. Build set and configuration
|
|
files can define new values extending the defaults. For example builds are
|
|
given a release number. This is typically a single number at the end of the
|
|
package name. For RTEMS this is set in the top level build set configuration
|
|
file with:
|
|
|
|
-------------------------------------------------------------
|
|
%define release 1
|
|
-------------------------------------------------------------
|
|
|
|
Once defined if can be accessed in a build set or package configuration file
|
|
with:
|
|
|
|
-------------------------------------------------------------
|
|
%{release}
|
|
-------------------------------------------------------------
|
|
|
|
The +sb-defaults+ command lists the defaults for your host. I will not include
|
|
the output of this command beause of its size.
|
|
|
|
-------------------------------------------------------------
|
|
$ ../source-builder/sb-defaults
|
|
-------------------------------------------------------------
|
|
|
|
Build Set Files
|
|
~~~~~~~~~~~~~~~
|
|
|
|
Build set files lets you list the packages in the build set you are defining
|
|
and have a file extension of +.bset+. Build sets can define macro variables,
|
|
inline include other files and reference other build set or package
|
|
configuration files.
|
|
|
|
Defining macros is performed with the +%define+ directive:
|
|
|
|
-------------------------------------------------------------
|
|
%define _target m32r-rtems4.11
|
|
-------------------------------------------------------------
|
|
|
|
The top level RTEMS build set files specify the target. This is used by other
|
|
referenced files or an undefined macro error is reported.
|
|
|
|
Inline including another file with the +%include+ directive continues
|
|
processing with the specified file returning to carry on from just after the
|
|
include point.
|
|
|
|
-------------------------------------------------------------
|
|
%include rtems-4.11-base.bset
|
|
-------------------------------------------------------------
|
|
|
|
This includes the RTEMS 4.11 base set of defines and checks. The configuration
|
|
paths as defined by +_configdir+ are scanned. The file extension is optional.
|
|
|
|
You reference build set or package configuration files by placing the file name
|
|
on a single line.
|
|
|
|
-------------------------------------------------------------
|
|
tools/rtems-binutils-2.22-1
|
|
-------------------------------------------------------------
|
|
|
|
The +_configdir+ path is scanned for +tools/rtems-binutils-2.22-1.bset+ or
|
|
+tools/rtems-binutils-2.22-1.cfg+. Build set files take precedent over package
|
|
configuration files. If +tools/rtems-binutils-2.22-1+ is a build set a new
|
|
instance of the build set processor is created and if the file is a package
|
|
configuration the package is built. This all happens once the build set file
|
|
has finished being scanned.
|
|
|
|
Configuration Files
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
Configuration files specify how to build a package. Configuration files are
|
|
scripts and have a +.cfg+ file extension. The script format is based loosely on
|
|
the RPM spec file format how-ever the use and purpose in this tool does not
|
|
compare with the functionality and therefore the important features of the spec
|
|
format RPM needs and uses.
|
|
|
|
Script Language
|
|
~~~~~~~~~~~~~~~
|
|
|
|
The script language is implemented in terms of directives. The directive list is:
|
|
|
|
[horizontal]
|
|
+%prep+:: The source preparation shell commands.
|
|
+%build+:: The build shell commands.
|
|
+%install+:: The package install shell commands.
|
|
+%clean+:: The package clean shell commands.
|
|
+%include+:: Inline include another configuration file.
|
|
+%package+:: The package being built.
|
|
+%name+:: The name of the package.
|
|
+%description+:: A package description. Useful when reporting about a build.
|
|
+%release+:: The package release. A number that is the release as built by this tool.
|
|
+%version+:: The package's verison string.
|
|
+%buildarch+:: The build architecture.
|
|
+%setup+:: Setup a source package.
|
|
+%source+:: Define a source code package. This directive is number.
|
|
+%patch+:: Define a patch. This directive is number.
|
|
+%warning+:: Print the following string as a warning and continue.
|
|
+%error+:: Print the following string as an error and exit.
|
|
+%define+:: Define a macro. Macros cannot be redefined, you must first undefine it.
|
|
+%undefine+:: Undefine a macro.
|
|
+%if+:: Start a conditional logic block that ends with a +%endif+.
|
|
+%ifn+:: Inverted start of a conditional logic block.
|
|
+%ifarch+:: Test the architecture against the following string.
|
|
+%ifnarch+:: Inverted test of the architecture
|
|
+%ifos+:: Test the host operating system.
|
|
+%else+:: Start the _else_ conditional logic block.
|
|
+%endfi+:: End the conditional logic block.
|
|
+%bconf_with+:: Test the build condition _with_ setting. This is the +--with-*+
|
|
command line option.
|
|
+%bconf_without+:: Test the build condition _without_ setting. This is the
|
|
+--without-*+ command line option.
|
|
|
|
%prep
|
|
^^^^^
|
|
|
|
The +%prep+ directive starts a block that continues until the next block
|
|
directive. The _prep_ or preparation block defines the setup of the package's
|
|
source and is a mix of RTEMS Source Builder directives and shell scripting. The
|
|
sequence is typically +%setup+ directives for source, +%patch+ directives to
|
|
patch the source mixed with some shell commands to correct any source issues.
|
|
A +%prep+ section starts with a +%setup+ command. This creates the package
|
|
source top level directory then is followed by the first source file.
|
|
|
|
-------------------------------------------------------------
|
|
<1> <2>
|
|
%setup -q -c -T -n %{name}-%{version}
|
|
%setup -q -T -D -n %{name}-%{version} -a0
|
|
-------------------------------------------------------------
|
|
|
|
<1> The package's name.
|
|
<2> The version of the package.
|
|
|
|
The source for a package is declared with the +%source*+ directive where +*+ is
|
|
a number. For example +%source0+ is the source 0 tar file and is defined with
|
|
something similar to this:
|
|
|
|
-------------------------------------------------------------
|
|
Source0: http://ftp.gnu.org/gnu/gdb/gdb-%{gdb_version}.tar.bz2
|
|
-------------------------------------------------------------
|
|
|
|
This URL is the primary location of the GNU GCC source code and the RTEMS
|
|
Source Builder can download the file from this location and by inspecting the
|
|
file extension use +bzip2+ decompression. When the +%prep+ section is processed
|
|
a check of the local +source+ directory is made to see if the file has already
|
|
been downloaded. If not found in the source cache directory the package is
|
|
downloaded from the URL. You can append other base URLs via the command line
|
|
option +--url+. This option accepts a comma delimited list of sites to try.
|
|
|
|
You can combine the source directive with connditional logic to implement a
|
|
default that can be overriden in the top level files. This lets you reuse a
|
|
generic build script with different sources. This happens if you have a private
|
|
source package with local modifications. The following example is taken from
|
|
the +gcc-4.8-1.cfg+ build script.
|
|
|
|
-------------------------------------------------------------
|
|
%ifn %{defined Source0}
|
|
Source0: ftp://ftp.gnu.org/gnu/gcc/gcc-%{gcc_version}/gcc-%{gcc_version}.tar.bz2
|
|
VersionContro0: git clone git://gcc.gnu.org/git/gcc.git <1>
|
|
%endif
|
|
-------------------------------------------------------------
|
|
|
|
<1> The version control directive is currently not implemented.
|
|
|
|
You could optionally have a few source files that make up the package. For
|
|
example GNU's GCC was a few tar files for a while and it is now a single tar
|
|
file. Support for multiple source files can be conditionally implemented with
|
|
the following scripting:
|
|
|
|
-------------------------------------------------------------
|
|
%{?source1:%setup -q -T -D -n %{name}-%{version} -a1}
|
|
-------------------------------------------------------------
|
|
|
|
The +source1+ macro value is checked and if present the command string after
|
|
the +:+ is executed. It is common to see a number of these present allowing top
|
|
level configuration files including a base configuration the ability to define
|
|
a number of source packages.
|
|
|
|
-------------------------------------------------------------
|
|
%{?source1:%setup -q -T -D -n %{name}-%{version} -a1}
|
|
%{?source2:%setup -q -T -D -n %{name}-%{version} -a2}
|
|
%{?source3:%setup -q -T -D -n %{name}-%{version} -a3}
|
|
-------------------------------------------------------------
|
|
|
|
Patching also occurs during the preparation stage. Patches are handled in a
|
|
similar way to the source packages. Most patches are based around the top of
|
|
the source tree. This is an example of the patch scripting for the GCC 4.8
|
|
series of compilers:
|
|
|
|
-------------------------------------------------------------
|
|
cd gcc-%{gcc_version} <1>
|
|
%{?patch0:%patch0 -p1} <2>
|
|
%{?patch1:%patch1 -p1}
|
|
%{?patch2:%patch2 -p1}
|
|
%{?patch3:%patch3 -p1}
|
|
%{?patch4:%patch4 -p1}
|
|
%{?patch5:%patch5 -p1}
|
|
%{?patch6:%patch6 -p1}
|
|
%{?patch7:%patch7 -p1}
|
|
%{?patch8:%patch8 -p1}
|
|
%{?patch9:%patch9 -p1}
|
|
cd .. <3>
|
|
-------------------------------------------------------------
|
|
|
|
<1> Change from the top of the source tree into the package being patched's top
|
|
directory.
|
|
<2> The conditional macro expansion checks if +%patch0+ is defined and if
|
|
defined issues the +%patch0" directive giving +-p1+ to the patch command.
|
|
<3> Return back to the top of the source tree.
|
|
|
|
%build
|
|
^^^^^^
|
|
|
|
The +%build+ directive starts a block that continues until the next block
|
|
directive. The build block is a series of shell commands that execute to build
|
|
the package. It assumes all source code has been unpacked, patch and adjusted
|
|
so the build will succeed.
|
|
|
|
The following is an example take from the GutHub STLink project [footnote:
|
|
STLink is a JTAG debugging device for the ST ARM family of processors.]:
|
|
|
|
-------------------------------------------------------------
|
|
%build
|
|
export PATH="%{_bindir}:${PATH}" <1>
|
|
|
|
cd texane-stlink-%{stlink_version} <2>
|
|
|
|
./autogen.sh <3>
|
|
|
|
%if "%{_build}" != "%{_host}"
|
|
CFLAGS_FOR_BUILD="-g -O2 -Wall" \ <4>
|
|
%endif
|
|
CPPFLAGS="-I $SB_TMPPREFIX/include/libusb-1.0" \ <5>
|
|
CFLAGS="$SB_OPT_FLAGS" \
|
|
LDFLAGS="-L $SB_TMPPREFIX/lib" \
|
|
./configure \ <6>
|
|
--build=%{_build} --host=%{_host} \
|
|
--verbose \
|
|
--prefix=%{_prefix} --bindir=%{_bindir} \
|
|
--exec-prefix=%{_exec_prefix} \
|
|
--includedir=%{_includedir} --libdir=%{_libdir} \
|
|
--mandir=%{_mandir} --infodir=%{_infodir}
|
|
|
|
%{__make} %{?_smp_mflags} all <7>
|
|
|
|
cd ..
|
|
-------------------------------------------------------------
|
|
|
|
<1> Setup the PATH environment variable. This is not always needed.
|
|
<2> This package builds in the source tree so enter it.
|
|
<3> The package is actually checked directly out from the github project and so
|
|
it needs its autoconf and automake files generated.
|
|
<4> Flags for a crosscompiled build.
|
|
<5> Various settings passed to configure to customise the build. In this
|
|
example an include path is being set to the install point of _libusb_. This
|
|
package requires _libusb_ is build before it.
|
|
<6> The +configure+ command. The RTEMS Source Builder provides all the needed
|
|
paths as macro variables. You just need to provide them to +configure+.
|
|
<7> Running make. Do not use +make+ directly, use the RTEMS Source Builder's
|
|
defined value. This value is specific to the host. A large number of
|
|
packages need GNU make and on BSD systems this is +gmake+. You can
|
|
optionally add the SMP flags if the packages build system can handle
|
|
parallel building with multiple jobs. The +_smp_mflags+ value is
|
|
automatically setup for SMP hosts to match the number of cores the host has.
|
|
|
|
%install
|
|
^^^^^^^^
|
|
|
|
The +%install+ directive starts a block that continues until the next block
|
|
directive. The install block is a series of shell commands that execute to
|
|
install the package. You can assumes the package has build correctly when this
|
|
shell script executes.
|
|
|
|
Never install the package to the actual _prefix_ the package was built
|
|
with. Always install to the RTEMS Source Builder's temporary path defined in
|
|
the macro variable +__tmpdir+. The RTEMS Source Builder sets up a shell
|
|
environment variable called +SB_BUILD_ROOT+ as the standard install point. Most
|
|
packages support adding +DESTDIR=+ to the _make install_ command.
|
|
|
|
Looking at the same example as in <<_build, %build>>:
|
|
|
|
-------------------------------------------------------------
|
|
%install
|
|
export PATH="%{_bindir}:${PATH}" <1>
|
|
rm -rf $SB_BUILD_ROOT <2>
|
|
|
|
cd texane-stlink-%{stlink_version} <3>
|
|
%{__make} DESTDIR=$SB_BUILD_ROOT install <4>
|
|
|
|
cd ..
|
|
-------------------------------------------------------------
|
|
|
|
<1> Setup the PATH environment variable. This is not always needed.
|
|
<2> Clean any installed files. This make sure the install is just what
|
|
the package installs and not any left over files from a broken build or
|
|
install.
|
|
<3> Enter the build directory. In this example it just happens to be the source
|
|
directory.
|
|
<4> Run +make install_ to install the package overriding the +DESTDIR+ make
|
|
variable.
|
|
|
|
%clean
|
|
^^^^^^
|
|
|
|
%include
|
|
^^^^^^^^
|
|
|
|
%package
|
|
^^^^^^^^
|
|
|
|
%name
|
|
^^^^^
|
|
|
|
%description
|
|
^^^^^^^^^^^^
|
|
|
|
%release
|
|
^^^^^^^^
|
|
|
|
%version
|
|
^^^^^^^^
|
|
|
|
%buildarch
|
|
^^^^^^^^^^
|
|
|
|
%setup
|
|
^^^^^^
|
|
|
|
%source
|
|
^^^^^^^
|
|
|
|
%patch
|
|
^^^^^^
|
|
|
|
%warning
|
|
^^^^^^^^
|
|
|
|
%error
|
|
^^^^^^
|
|
|
|
%define
|
|
^^^^^^^
|
|
|
|
%undefine
|
|
^^^^^^^^^
|
|
|
|
%if
|
|
^^^
|
|
|
|
%ifn
|
|
^^^^
|
|
|
|
%ifarch
|
|
^^^^^^^
|
|
|
|
%ifnarch
|
|
^^^^^^^^
|
|
|
|
%ifos
|
|
^^^^^
|
|
|
|
%else
|
|
^^^^^
|
|
|
|
%endfi
|
|
^^^^^^
|
|
|
|
%bconf_with
|
|
^^^^^^^^^^^
|
|
|
|
%bconf_without
|
|
^^^^^^^^^^^^^^
|
|
|
|
|
|
RTEMS Build Sets
|
|
----------------
|
|
|
|
Configuration files are typically structured as outer files that are specific
|
|
to a version of the package being built and become more generic as you move
|
|
deeper. The outter layers are required to define various macro.
|
|
|
|
|
|
Set Builder and the Builder
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The RTEMS Source Builder provides two commands, the +sb-set-builder+ to build sets of
|
|
packages and the +sb-builder+ to build a specific package. The set builder uses
|
|
the builder to build a set of packages. You could write a shell script that did
|
|
the same thing so the set builder is a convenience command that allows you to
|
|
define and control specific features of the packages you are building. The set
|
|
builder looks for files with the +.bset" extension in the +config+
|
|
directories. The builder command uses configuration files which have the +.cfg+
|
|
file extension to control the build. The configuration files are written in a
|
|
script language based on the _spec_ format the RPM builder uses. They also
|
|
live in the +config+ directories.
|
|
|
|
The build set files for the RTEMS 4.11 can be found in +rtems/4.11/+. There is
|
|
one per architecture RTEMS supports. This allows variation between
|
|
architectures is bugs or patches are needed. Sometimes a specific version of a
|
|
tool may needed to resolve an issue in an architecture, how-ever that version
|
|
may have a bug in another architecture. We also want to limit architecture
|
|
specific patches to the architecture it relates to. This avoids any crosstalk a
|
|
patch may have with another architecture. An example of this is the NIOS2
|
|
tools. They are built using a version of GCC released by Altera currently not
|
|
in the Free Software Foundation's GCC project.
|
|
|
|
This is the build set for the Blackfin processor or +bfin+.
|
|
|
|
-------------------------------------------------------------
|
|
#
|
|
# Tools Set for RTEMS 4.10
|
|
#
|
|
|
|
%define rtems_version 4.10 <1>
|
|
|
|
%define release 1 <2>
|
|
|
|
package: rtems-%{rtems_version}-%{_target}-%{release} <3>
|
|
|
|
#
|
|
# Project custom message
|
|
#
|
|
%define gcc_version_message RTEMS %{rtems_version}-%{release},gcc-%{gcc_version}/newlib-%{newlib_version} <4>
|
|
|
|
#
|
|
# Tools configuration.
|
|
#
|
|
rtems-binutils-2.20.1-1 <5>
|
|
rtems-gcc-4.4.7-newlib-1.18.0-1
|
|
rtems-gdb-7.3.1-1
|
|
-------------------------------------------------------------
|
|
|
|
<1> Define the version of RTEMS.
|
|
<2> Define the release. This allows us to number the tool releases.
|
|
<3> The top level name of the package. The finaly tar file name.
|
|
<4> The GCC configuration allow a custom message to be embedded into GCC.
|
|
<5> The list of packages this build set contains.
|
|
|
|
Currently the syntax of the set builder scripts is limited. It support
|
|
comments, the package command, macros (the +%{}+), and defining macros
|
|
(+%define+). It is planned to allow more of the configuration file syntax in
|
|
the future.
|
|
|
|
The builder uses configuration files that allow the full range of the
|
|
configuration script syntax. Configuration files follow most of the RPM spec
|
|
file format. They support macros and logic as well as the ability to include
|
|
other configuration files. The ability to include other configuration files
|
|
allow a simple way to configuration control the builds. Configuration files
|
|
have four main areas:
|
|
|
|
. Descriptions and definitions.
|
|
+
|
|
The description lists various useful pieces of information about the
|
|
package. None of this is currently enforced how-ever it is good practice to
|
|
provide it. The definitions are the sources and the patches.
|
|
. Preparation
|
|
+
|
|
The preparation is the set up of the source code ready for building. The set up
|
|
follows the unusual command structure used by RPM. The follwing macro
|
|
trickshows how to conditional patch the source if a patch has been declared.
|
|
+
|
|
-------------------------------------------------------------
|
|
cd expat-%{expat_version}
|
|
%{?patch0:%patch0 -p1}
|
|
cd ..
|
|
-------------------------------------------------------------
|
|
+
|
|
. Build
|
|
+
|
|
The build phase. This is a fragment of shell script that can be mixed with
|
|
conditional configuration scripting to create the list of build commands.
|
|
+
|
|
. Install
|
|
+
|
|
The install phase. Again this is a fragment of shell script.
|
|
|
|
This is a configuration script to build gdb:
|
|
|
|
-------------------------------------------------------------
|
|
#
|
|
# GDB 7.xx Version 1.
|
|
#
|
|
# This configuration file configure's, make's and install's gdb.
|
|
#
|
|
|
|
%include %{_configdir}/checks.cfg <1>
|
|
|
|
Name: %{_target}-gdb-%{gdb_version}-%{release} <2>
|
|
Summary: GDB v%{gdb_version} for target %{_target} on host %{_host}
|
|
Version: %{gdb_version}
|
|
Release: %{release}
|
|
URL: http://www.gnu.org/software/gdb/
|
|
BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
|
|
|
|
#
|
|
# Source
|
|
#
|
|
Source0: http://ftp.gnu.org/gnu/gdb/gdb-%{gdb_version}.tar.bz2 <3>
|
|
VersionControl0 git clone git://sourceware.org/git/gdb.git
|
|
|
|
#
|
|
# Prepare the source code.
|
|
#
|
|
%prep <4>
|
|
%setup -q -c -T -n %{name}-%{version}
|
|
cd gdb-%{gdb_version}
|
|
%{?patch0:%patch0 -p1}
|
|
cd ..
|
|
|
|
%build <5>
|
|
export PATH="%{_bindir}:${PATH}"
|
|
mkdir -p build
|
|
cd build
|
|
%if "%{_build}" != "%{_host}"
|
|
CFLAGS_FOR_BUILD="-g -O2 -Wall" \
|
|
%endif
|
|
CFLAGS="$SB_OPT_FLAGS" \
|
|
../gdb-%{gdb_version}/configure \
|
|
--build=%{_build} --host=%{_host} \
|
|
--target=%{_target} \
|
|
--verbose --disable-nls \
|
|
--without-included-gettext \
|
|
--disable-win32-registry \
|
|
--disable-werror \
|
|
--enable-sim \
|
|
--with-expat \
|
|
--with-python \
|
|
--prefix=%{_prefix} --bindir=%{_bindir} \
|
|
--exec-prefix=%{_exec_prefix} \
|
|
--includedir=%{_includedir} --libdir=%{_libdir} \
|
|
--mandir=%{_mandir} --infodir=%{_infodir}
|
|
|
|
%{__make} %{?_smp_mflags} all
|
|
cd ..
|
|
|
|
%install <6>
|
|
export PATH="%{_bindir}:${PATH}"
|
|
rm -rf $SB_BUILD_ROOT
|
|
|
|
cd build
|
|
%{__make} DESTDIR=$SB_BUILD_ROOT install
|
|
|
|
# Dropped in FSF-binutils-2.9.5, but Cygwin still ships it.
|
|
rm -rf $SB_BUILD_ROOT%{_infodir}/configure.info*
|
|
|
|
rm -f $SB_BUILD_ROOT%{_infodir}/dir
|
|
touch $SB_BUILD_ROOT%{_infodir}/dir
|
|
|
|
cd ..
|
|
-------------------------------------------------------------
|
|
|
|
<1> Including a file. The +_configdir+ macro searchs a list of paths.
|
|
<2> The description section.
|
|
<3> The source file as a URL. If not found in the +sources+ directories it is
|
|
downloaded.
|
|
<4> Preparing the source code.
|
|
<5> The commands to build +gdb+.
|
|
<6> The installation phase. Notice the +DESTDIR=+ feature is used.
|
|
|
|
Controlling Configurations
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
This is a simple process of including the specific pieces you need. There
|
|
typically is three layers where the top level is specific and each sub-layer is
|
|
more generic configured by the layer above it. The typical layering is:
|
|
|
|
. Build Set
|
|
. Package definition
|
|
. Package configuration
|
|
|
|
The build set defines the packages to be built plus any specific configuration
|
|
needed. Some packages default to standard values if the build set does not
|
|
provide any specific configuration and some configurations raise an error
|
|
indicating a required configuration is missing.
|
|
|
|
Using the RTEMS 4.10 Tools Set build as an example the build set configuration
|
|
is:
|
|
|
|
-------------------------------------------------------------
|
|
#
|
|
# Tools Set for RTEMS 4.10
|
|
#
|
|
|
|
%define rtems_version 4.10
|
|
|
|
%define release 1 <1>
|
|
|
|
package: rtems-%{rtems_version}-%{_target}-%{release}
|
|
|
|
#
|
|
# Project custom message
|
|
#
|
|
%define gcc_version_message RTEMS %{rtems_version}-%{release},gcc-%{gcc_version}/newlib-%{newlib_version}
|
|
|
|
#
|
|
# Tools configuration.
|
|
#
|
|
rtems-binutils-2.20.1-1 <2>
|
|
rtems-gcc-4.4.7-newlib-1.18.0-1
|
|
rtems-gdb-7.3.1-1
|
|
-------------------------------------------------------------
|
|
|
|
<1> The release of the RTEMS 4.10 tools package.
|
|
<2> The build configurations. These reference the specific version of the tools
|
|
including the related patches. You should note the configurations referenced
|
|
are RTEMS specific, that is prefixed with +rtems-+.
|
|
|
|
The GCC and Newlib file +rtems-gcc-4.4.7-newlib-1.18.0-1+ is:
|
|
|
|
-------------------------------------------------------------
|
|
#
|
|
# GCC 4.4.7, Newlib 1.18.0
|
|
#
|
|
|
|
%include %{_configdir}/checks.cfg <1>
|
|
%include %{_configdir}/base.cfg <2>
|
|
|
|
%define gcc_version 4.4.7 <3>
|
|
%define newlib_version 1.18.0
|
|
%define mpfr_version 2.4.1
|
|
%define mpc_version 0.8.2
|
|
%define gmp_version 5.0.5
|
|
|
|
%define with_threads 1 <4>
|
|
%define with_plugin 0
|
|
%define with_iconv 1
|
|
|
|
#
|
|
# AVR C++ does not work.
|
|
# configure: error: unable to detect exception model
|
|
#
|
|
%if %{_target} == avr-rtems4.10 <5>
|
|
%define enable_cxx 0
|
|
%endif
|
|
|
|
#
|
|
# M32C C++ does not work.
|
|
# gcc-4.4.7/libstdc++-v3/src/mt_allocator.cc:76: error: cast from 'void*' to 'size_t' loses precision
|
|
#
|
|
%if %{_target} == m32c-rtems4.10
|
|
%define enable_cxx 0
|
|
%endif
|
|
|
|
%ifn %{defined enable_cxx} <6>
|
|
%define enable_cxx 1
|
|
%endif
|
|
|
|
#
|
|
# The RTEMS 4.10 patches
|
|
#
|
|
Patch0: gcc-core-4.4.7-rtems4.10-20120314.diff <7>
|
|
%if %{enable_cxx}
|
|
Patch1: gcc-g++-4.4.7-rtems4.10-20120314.diff
|
|
%endif
|
|
Patch10: newlib-1.18.0-rtems4.10-20110518.diff
|
|
|
|
#
|
|
# The gcc/newlib build instructions. We use 4.4 Release 1.
|
|
#
|
|
%include %{_configdir}/gcc-4.4-1.cfg <8>
|
|
-------------------------------------------------------------
|
|
|
|
<1> Perform some standard checks such as the release being set.
|
|
<2> Set up some standard macros needed by most configure type packages.
|
|
<3> The specific versions of the various parts that make a GCC embedded
|
|
cross-compiler.
|
|
<4> Configure some specific parts of GCC and Newlib for RTEMS.
|
|
<5> Disable C++ for the AVR target because it does not build for RTEMS.
|
|
<6> Default is to build C++.
|
|
<7> The various patches. This file's revision increases with each patch change.
|
|
<8> The generic GCC/Newlib build configuration for gcc-4.4.x.
|
|
|
|
Project Configuration
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The RTEMS Source Builder has a +config+ and +patches+ directory that contain some
|
|
useful and often needed configurations and patches. You do not need to add your
|
|
project specific configurations into the RTEMS Source Builder. You can create a
|
|
private set and then use the RTEMS Source Builder to build your packages.
|
|
|
|
Create a +config+ directory and place your build sets and configuration in
|
|
them. If you have private patches add them to a +patches+ directory next to the
|
|
+config+ directiory. When you run a RTEMS Source Builder command it will first search
|
|
the for the specific file then the local +config+ directoy then the Source
|
|
Builder's +config+ directory. The same goes for +patches+.
|
|
|
|
For example of this set up look in the +rtems+ directory in the Source
|
|
Builder. It is actually a standard alone project configuration private to the
|
|
RTEMS project.
|
|
|
|
If you are an open source project and you find the RTEMS Source Builder useful and
|
|
would like your configuration held in the RTEMS Source Builder's repository please
|
|
contact me directly.
|
|
|
|
The Builder
|
|
~~~~~~~~~~~
|
|
|
|
TBD
|
|
|
|
Commands
|
|
--------
|
|
|
|
Checker (sb-check)
|
|
~~~~~~~~~~~~~~~~~~
|
|
|
|
This commands checks your system is set up correctly.
|
|
|
|
-------------------------------------------------------------
|
|
$ ./source-builder/sb-check --help
|
|
sb-check: [options] [args]
|
|
RTEMS Source Builder, an RTEMS Tools Project (c) 2012 Chris Johns
|
|
Options and arguments:
|
|
--force : Create directories that are not present
|
|
--trace : Trace the execution (not current used)
|
|
--dry-run : Do everything but actually run the build
|
|
--warn-all : Generate warnings
|
|
--no-clean : Do not clean up the build tree
|
|
--no-smp : Run with 1 job and not as many as CPUs
|
|
--rebuild : Rebuild (not used)
|
|
--host : Set the host triplet
|
|
--build : Set the build triplet
|
|
--target : Set the target triplet
|
|
--prefix path : Tools build prefix, ie where they are installed
|
|
--prefixbase path :
|
|
--topdir path : Top of the build tree, default is $PWD
|
|
--configdir path : Path to the configuration directory, default: ./config
|
|
--builddir path : Path to the build directory, default: ./build
|
|
--sourcedir path : Path to the source directory, default: ./source
|
|
--tmppath path : Path to the temp directory, default: ./tmp
|
|
--log file : Log file where all build out is written too
|
|
--url url : URL to look for source
|
|
--targetcflags flags : List of C flags for the target code
|
|
--targetcxxflags flags : List of C++ flags for the target code
|
|
--libstdcxxflags flags : List of C++ flags to build the target libstdc++ code
|
|
--with-<label> : Add the --with-<label> to the build
|
|
--without-<label> : Add the --without-<label> to the build
|
|
-------------------------------------------------------------
|
|
|
|
Set Builder (sb-set-builder)
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
This command builds a set as described in a build set. Build set files have the
|
|
extension of +.bset+.
|
|
|
|
-------------------------------------------------------------
|
|
$ ./source-builder/sb-set-builder --help
|
|
sb-set-builder: [options] [args]
|
|
RTEMS Source Builder, an RTEMS Tools Project (c) 2012 Chris Johns
|
|
Options and arguments:
|
|
--force : Create directories that are not present
|
|
--trace : Trace the execution (not current used)
|
|
--dry-run : Do everything but actually run the build
|
|
--warn-all : Generate warnings
|
|
--no-clean : Do not clean up the build tree
|
|
--no-smp : Run with 1 job and not as many as CPUs
|
|
--rebuild : Rebuild (not used)
|
|
--host : Set the host triplet
|
|
--build : Set the build triplet
|
|
--target : Set the target triplet
|
|
--prefix path : Tools build prefix, ie where they are installed
|
|
--prefixbase path :
|
|
--topdir path : Top of the build tree, default is $PWD
|
|
--configdir path : Path to the configuration directory, default: ./config
|
|
--builddir path : Path to the build directory, default: ./build
|
|
--sourcedir path : Path to the source directory, default: ./source
|
|
--tmppath path : Path to the temp directory, default: ./tmp
|
|
--log file : Log file where all build out is written too
|
|
--url url : URL to look for source
|
|
--targetcflags flags : List of C flags for the target code
|
|
--targetcxxflags flags : List of C++ flags for the target code
|
|
--libstdcxxflags flags : List of C++ flags to build the target libstdc++ code
|
|
--with-<label> : Add the --with-<label> to the build
|
|
--without-<label> : Add the --without-<label> to the build
|
|
--list-configs : List available configurations
|
|
--list-bsets : List available build sets
|
|
-------------------------------------------------------------
|
|
|
|
Set Builder (sb-builder)
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
This command builds a configuration as described in a configuration
|
|
file. Configuration files have the extension of +.cfg+.
|
|
|
|
-------------------------------------------------------------
|
|
$ ./source-builder/sb-builder --help
|
|
sb-builder: [options] [args]
|
|
RTEMS Source Builder, an RTEMS Tools Project (c) 2012 Chris Johns
|
|
Options and arguments:
|
|
--force : Create directories that are not present
|
|
--trace : Trace the execution (not current used)
|
|
--dry-run : Do everything but actually run the build
|
|
--warn-all : Generate warnings
|
|
--no-clean : Do not clean up the build tree
|
|
--no-smp : Run with 1 job and not as many as CPUs
|
|
--rebuild : Rebuild (not used)
|
|
--host : Set the host triplet
|
|
--build : Set the build triplet
|
|
--target : Set the target triplet
|
|
--prefix path : Tools build prefix, ie where they are installed
|
|
--prefixbase path :
|
|
--topdir path : Top of the build tree, default is $PWD
|
|
--configdir path : Path to the configuration directory, default: ./config
|
|
--builddir path : Path to the build directory, default: ./build
|
|
--sourcedir path : Path to the source directory, default: ./source
|
|
--tmppath path : Path to the temp directory, default: ./tmp
|
|
--log file : Log file where all build out is written too
|
|
--url url : URL to look for source
|
|
--targetcflags flags : List of C flags for the target code
|
|
--targetcxxflags flags : List of C++ flags for the target code
|
|
--libstdcxxflags flags : List of C++ flags to build the target libstdc++ code
|
|
--with-<label> : Add the --with-<label> to the build
|
|
--without-<label> : Add the --without-<label> to the build
|
|
--list-configs : List available configurations
|
|
-------------------------------------------------------------
|
|
|
|
Host Setups
|
|
-----------
|
|
|
|
MacOS X
|
|
~~~~~~~
|
|
|
|
The RTEMS Source Builder has been tested on Mountain Lion. You will need to
|
|
install the Xcode app using the _App Store_ tool, run Xcode and instal the
|
|
Developers Tools package within Xcode.
|
|
|
|
Ubuntu
|
|
~~~~~~
|
|
|
|
The latest testing was with 12.10. A minimal installation was used and the
|
|
following packages installed.
|
|
|
|
-------------------------------------------------------------
|
|
$ sudo apt-get build-dep binutils gcc g++ gdb unzip git
|
|
-------------------------------------------------------------
|
|
|
|
Raspbian
|
|
~~~~~~~~
|
|
|
|
The is the Debian distribution for the Raspberry Pi. The following packages are
|
|
required.
|
|
|
|
-------------------------------------------------------------
|
|
$ sudo apt-get install autoconf automake bison flex binutils gcc g++ gdb \
|
|
texinfo unzip ncurses-dev python-dev
|
|
-------------------------------------------------------------
|
|
|
|
It is recommended you get Model B of the Pi with 512M of memory and to mount a
|
|
remote disk over the network. The tools can be build with a prefix under your
|
|
home directory as recommended and end up on the SD card.
|
|
|
|
CentOS 6
|
|
~~~~~~~~
|
|
|
|
The following packages are required on a minimal CentOS 6.3 installation:
|
|
|
|
-------------------------------------------------------------
|
|
# yum install autoconf automake binutils gcc gcc-c++ gdb make patch \
|
|
bison flex xz unzip ncurses-devel texinfo zlib-devel python-devel git
|
|
-------------------------------------------------------------
|
|
|
|
The minimal CentOS distrbution is a specific DVD that installs a minimal
|
|
system. If you use a full system some of these packages may have been
|
|
installed.
|
|
|
|
History
|
|
-------
|
|
|
|
The RTEMS Source Builder is a stand alone tool based on another tool called the
|
|
'SpecBuilder'. The SpecBuilder was written for the RTEMS project too give me a
|
|
way to build tools on hosts that did not support RPMs. At the time the RTEMS
|
|
tools maintainer only used spec files to create various packages. This meant I
|
|
had either spec files, RPM files or SRPM files. The RPM and SPRM files where
|
|
useless because you needed an 'rpm' type tool to extract and manage them. There
|
|
are versions of 'rpm' for a number of non-RPM hosts how-ever these proved to be
|
|
in various broken states and randomally maintained. The solution I settled on
|
|
was to use spec files so I wrote a Python based tool that parsed the spec file
|
|
format and allowed me to create a shell script I could run to build the
|
|
package. This approach proved successful and I was able to track the RPM
|
|
version of the RTEMS tools on a non-RPM host over a number of years. How-ever
|
|
the SpecBuilder tool did not help me build tools or other packages not related
|
|
to the RTEMS project where there was no spec file I could use so I needed
|
|
another tool. Rather than start again I decided to take the parsing code for
|
|
the spec file format and build a new tool called the RTEMS Source Builder.
|