Thomas,
On Thu, Oct 23, 2014 at 11:49 AM, Thomas Petazzoni
Post by Thomas PetazzoniDear Bryan Hundven,
Post by Bryan HundvenIf you are using crosstool-ng, you have to save steps if you want to
not build the prereqs for building gcc (say you are working on gcc
specifically) over and over again. autocrossgen's build system uses
GNU/Make rather then Bash. So you can just delete the build/gcc*, type
make and the build will leave off at configuring and building gcc
instead of starting the whole build process over from scratch.
If all what you want is to be able to restart the build of the
toolchain like you say, why not give a try to Buildroot
(http://buildroot.org) ? It's written entirely in make, and works
exactly like you say: if you want to restart the build only of one
make gcc-rebuild
See also
http://buildroot.org/downloads/manual/manual.html#_advanced_usage and
specifically the part "8.11.6. Using Buildroot during development".
Buildroot already supports uClibc, (e)glibc and musl, for a wide range
of architectures.
Best regards,
Thomas
I can agree that buildroot is one possibility.
Trust that I have evaluated a lot of different systems before coming
to the conclusion of starting autocrossgen. Lets quickly go through
some of those evaluations and why I chose not to use `X':
## crosstool-ng
With the elephant in the room, lets just get this one out of the way quickly.
* It is slowly updated, and quickly out of date.
* Trying to bend it to use daily/weekly snapshots of binutils (needed
for building gcc from snapshots or subversion) is not supported
upstream.
* To the same point, getting it to build gcc snapshots/subversion is
somewhat painful, since these types of changes are not allowed in
upstream crosstool-ng.
* The previous two features not being supported upstream means I have
to have my own fork of ct-ng, which I don't want to do because I
sometimes dislike working on the code-base itself. I usually make
commits to crosstool-ng because no other tool has as much support and
focus on just making a toolchain.
* Rebuilding from specific points in the build is painful.
My points on crosstool-ng are specific to my use-case of what I need
for a specific set of projects I am interested in. If you are building
a stable toolchain that you want to be able to reproduce over the
lifetime of an embedded project, crosstool-ng is the tool you want!
## cgen
This tool is fairly old, and I've spoke with Frank Ch. Eigler about me
possibly sending him changes to update this tool, it's code-base is
pretty complicated and out of date (uses scheme?!).
## musl-cross
I probably don't need to go into as many points with this one, it only
supports musl-libc. It is a very simple code-base though. And useful
if all you need to do is test musl-libc.
## buildroot
All I need to do is build a toolchain, a quick build of the linux
kernel for the architecture at hand and maybe u-boot if needed, run it
under qemu to make sure things "build and run". Buildroot does this
and much more, so much more that using it for my small use-case feels
to me like swatting a fly with a sledge hammer. I didn't look into
using buildroot to build snapshot/git versions of binutils or
snapshots/subversion versions of gcc, but that is a need for my
use-case.
I'm *NOT* saying that "I think buildroot is useless". Because that
would be bad judgement of where I'm coming from. I use buildroot for
many of my embedded projects. I like it much for what it does, but it
doesn't help me to make changes to gcc and others, quickly spin just a
toolchain build, and run a few tests.
## ptxdist, yocto, gentoo, et-alii
These are about the same as buildroot for me. too much infrastructure
around building a target image, and these tools do a lot more then
buildroot, such as creating 'sdk' tarballs for application developers,
and developer tools for the target.
***
The open-source landscape has a lot of options, and last but not least
is running the build by hand... which I'm sure we have all either done
on our own, or guided by linux-from-scratch (or cross-lfs).
Most gcc developers use the combined method, where you just extract
gcc to a source directory: 'combined'
then extract binutils in the same 'combined' directory (overwriting
any pre-existing files).
gmp, mpfr, mpc, isl, cloog, and libelf get copied (as those names) to
the root directory of the combined folder.
Then you create and change to a build folder and then you configure
(running configure from the combined folder from the build directory)
and build a bootstrap. The process is documented very well here
(although a bit out of date, it still uses cvs):
https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc
https://gcc.gnu.org/install/
***
## Autocrossgen builds:
- Binutils for the host (with gmp, mpfr, mpc, isl, cloog, and libelf combined)
- Gcc pass1 to build the libc (with the same libraries in the combined build)
- Libc of choice (discovered by reading the last quad of the tuple,
*-*-linux-gnu* for glibc, *-*-linux-uclibc* for uclibc, and
*-*-linux-musl* for musl-libc)
- Gcc final (with combined libraries)
- Binutils for the target (also with combined libraries)
The combined libraries are simpler to manage then writing a bunch of
build architecture to support building each library separately and
making sure that the major component being built (gcc or binutils) are
finding the right version, and possibly not the host version. It's a
matter of consistency.
You can clone autocrossgen right now and create either a arm or
powerpc toolchain like so:
```
git clone https://github.com/bhundven/autocrossgen
cd autocrossgen
./autogen.sh
./configure --prefix=arm-acg-toolchain --target=arm-unknown-linux-gnueabi
make all
```
or for powerpc (32):
```
git clone https://github.com/bhundven/autocrossgen
cd autocrossgen
./autogen.sh
./configure --prefix=powerpc-acg-toolchain --target=powerpc-unknown-linux-gnu
make all
```
to evaluate what I've done for yourself. I've mentioned before that it
is at a very early stage. There are missing checks, issues with
parallel builds, lack of support for specific architectures, which I
hope most of this is resolved in some time.
I hope this is a better explanation of autocrossgen. It doesn't
replace any existing project, it just fits a small niche I have to
"itch" :)
-Bryan
--
For unsubscribe information see http://sourceware.org/lists.html#faq