[ANNOUNCE] OSELAS.Toolchain() 1.1.0 released
Robert Schwebel
robert@schwebel.de
Tue Mar 6 07:13:00 GMT 2007
Hi,
On Mon, Mar 05, 2007 at 09:32:46PM +0100, Jan-Benedict Glaw wrote:
> On Mon, 2007-03-05 16:17:50 +0100, Robert Schwebel <robert@schwebel.de> wrote:
> > Hildesheim, Germany - Pengutronix has released version 1.1.0 of the Open
> > Source GNU toolchain build system OSELAS.Toolchain(). It can be used to
> > build cross compilers for a variety of embedded Linux systems, the
> > complete feature matrix and homepage of the project is on
> >
> > http://www.pengutronix.de/oselas/toolchain/index_en.html
>
> On a first view, the scripts and Makefiles look quite clean.
I hope so :-) Our first attempt was to start with crosstool and clean it
up in a step-by-step way, but after having tried several possibilities
it turned out that
- crosstool has a bunch of hacks which are poorly documented; they may
be necessary to build 2.95.3 or some other old gcc version, but nobody
knows if they are necessary today (and it is our aim to build
toolchains recent enough that they are a) usable for real-life
projects and b) close enough to upstream that our patches can be
integrated)
- the more we tried to cleanup crosstool, it turned out that all we
needed was already there in PTXdist:
* a dependency mechanism (just add 'select FOO' to BAR's .in
file if you want an autogenerated dependency)
* a staging structure (get, prepare, extract, compile, install,
targetinstall)
* an automatic patch mechanism (just throw your quilt-style
patch stack into patches/$PACKET/generic/ and it is
automatically applied)
* a set of sophisticated makefiles which allow to misuse ptxdist
to build something which is different from what it was
intended to (Linux userlands) by having an overwrite mechanism
(in ptxdist, project specific .make files overwrite ptxdist
supplied ones and you can define your own Kconfig structure).
* a clear separation of host (runs on the development machine)
vs. cross (runs on development machine but builds for the
target architecture) vs. target (runs on the target
architecture) packets.
So what we now have is a clear per-packet structure:
cross-binutils{.in,.make}
cross-gcc-first{.in,.make}
cross-gcc-second{.in,.make}
cross-gdb{.in,.make}
cross-toolchain{.in,.make}
gdb.make
glibc-crt{.in,.make}
glibc-final{.in,.make}
glibc-headers{.in,.make}
glibc{.in,.make}
glibc-linuxthreads{.in,.make}
glibc-ports{.in,.make}
kernel-headers{.in,.make}
Each one cares about exactly what it says and has it's own corresponding
directory in patches/.
There are tons of predefined toolchain combinations in ptxconfigs/, and
selecting one of them is just
ptxdist select ptxconfigs/my_favourite_toolchain
and running
ptxdist go
which builds the toolchain into /opt/OSELAS.Toolchain-1.1.0/*, following
the old structure from crosstool (we felt that it is better to see on a
higher directory level for which architecture the toolchain is, because
you usually have for example an arm-v4t board and want to look which
toolchains are available via tab expansion, instead of first deciding
that you want to use gcc-4.1.2 and then check which architectures are
available).
> Is it planed to allow building right off CVS/SVN/GIT trunk sandboxes
> of the projects (gcc, binutils+gdb, glibc, linux)?
There is no generic method yet, but you can probably tweak it like this:
You can use file:// style URLs for the packets, and changing for example
CROSS_GCC_FIRST_URL := file://$(PTXDIST_WORKSPACE)/sandbox/gcc/
in cross-gcc-first.make makes this your working directory. PTXdist
checks if file urls point to files (which are taken as tarballs and
extracted to build-{target,host,cross}) or directories; if they are
directories, they are just linked into the corresponding build dirs.
I'm just not sure if it works for packets which are used more than one
time. Just try it out.
The "clean" solution is probably that you add a config switch which says
something like
[ ] use custom URL
and, if being enabled, enables a second, string type, config entry which
lets you enter the URL. The makefile then has to decide which one to
use.
What also dosen't work out of the box at the moment is using gcc
snapshots. You'll notice if you select the gcc-4.2-* snapshots, which
don't download automatically. So what we currently do is to download
them manually and put them into the source dir, which can be configured
with 'ptxdist setup' -> source dir.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list