mirror of
https://github.com/crosstool-ng/crosstool-ng.git
synced 2024-12-19 04:47:52 +00:00
1906cf93f8
You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
109 lines
4.9 KiB
Plaintext
109 lines
4.9 KiB
Plaintext
File.........: overview.txt
|
|
Content......: Overview of how ct-ng works.
|
|
Copyrigth....: (C) 2006 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
|
|
License......: see COPYING in the root of this package
|
|
________________
|
|
/
|
|
Introduction /
|
|
_____________/
|
|
|
|
crosstool-NG aims at building toolchains. Toolchains are an essential component
|
|
in a software development project. It will compile, assemble and link the code
|
|
that is being developped. Some pieces of the toolchain will eventually end up
|
|
in the resulting binary/ies: static libraries are but an example.
|
|
|
|
So, a toolchain is a very sensitive piece of software, as any bug in one of the
|
|
components, or a poorly configured component, can lead to execution problems,
|
|
ranging from poor performance, to applications ending unexpectedly, to
|
|
mis-behaving software (which more than often is hard to detect), to hardware
|
|
damage, or even to human risks (which is more than regretable).
|
|
|
|
Toolchains are made of different piece of software, each being quite complex
|
|
and requiring specially crafted options to build and work seamlessly. This
|
|
is usually not that easy, even in the not-so-trivial case of native toolchains.
|
|
The work reaches a higher degree of complexity when it comes to cross-
|
|
compilation, where it can becomes quite a nightmare...
|
|
|
|
Some cross-toolchain exits on the internet, and can be used for general
|
|
development, but they have a number of limitations:
|
|
- they can be general purpose, in that they are configured for the majority:
|
|
no optimisation for your specific target,
|
|
- they can be prepared for a specific target and thus are not easy to use,
|
|
nor optimised for, or even supporting your target,
|
|
- they often are using ageing components (compiler, C library, etc...) not
|
|
supporting special features of your shiny new processor;
|
|
On the other side, these toolchain offer some advantages:
|
|
- they are ready to use and quite easy to install and setup,
|
|
- they are proven if used by a wide community.
|
|
|
|
But once you want to get all the juice out of your specific hardware, you will
|
|
want to build your own toolchain. This is where crosstool-ng comes into play.
|
|
|
|
There are also a number of tools that builds toolchains for specific needs,
|
|
which is not really scalable. Examples are:
|
|
- buildroot (buildroot.uclibc.org) whose main puprpose is to build root file
|
|
systems, hence the name. But once you have your toolchain with buildroot,
|
|
part of it is installed in the root-to-be, so if you want to build a whole
|
|
new root, you either have to save the existing one as a template and
|
|
restore it later, or restart again from scratch. This is not convenient,
|
|
- ptxdist (www.pengutronix.de/software/ptxdist), whose purpose is very
|
|
similar to buildroot,
|
|
- other projects (openembeded.org for example), which is again used to
|
|
build root file systems.
|
|
|
|
crosstool-NG is really targetted at building toolchains, and only toolchains.
|
|
It is then up to you to use it the way you want.
|
|
|
|
___________
|
|
/
|
|
History /
|
|
________/
|
|
|
|
crosstool was first 'conceived' by Dan Kegel, which offered it to the community,
|
|
as a set of scripts, a repository of patches, and some pre-configured, general
|
|
purpose setup files to be used to configure crosstool. This is available at
|
|
www.kegel.com/crosstool, and the subversion repository is hosted on google at
|
|
http://code.google.com/p/crosstool/.
|
|
|
|
At the time of writing, crosstool only supports building with one C library,
|
|
namely glibc, and one C compiler, gcc; it is cripled with historical support
|
|
for legacy components, and is some kind of a mess to upgrade.
|
|
|
|
I once managed to add support for uClibc-based toolchains, but it did not make
|
|
into mainline, mostly because I don't have time to port the patch forward to
|
|
the new versions, due in part to the big effort it was taking.
|
|
|
|
So I decided to clean up crosstool in the state it was, re-order the things
|
|
in place, and add appropriate support for what I needed, that is uClibc
|
|
support.
|
|
|
|
The only option left to me was rewrite crosstool from scratch. I decided to go
|
|
this way, and name the new implementation ct-ng, standing for crosstool Next
|
|
Generation, as many other comunity projects do, and as a wink at the TV series
|
|
"Star Trek: The Next Generation". ;-)
|
|
|
|
_____________
|
|
/
|
|
Operation /
|
|
__________/
|
|
|
|
ct-ng is configured by a configurator presenting a menu-stuctured set of
|
|
options. These options let you specify the way you want your toolchain built,
|
|
where you want it installed, what architecture and specific processor it
|
|
will support, the version of the components you want to use, etc... The
|
|
value for those options are then stored in a configuration file.
|
|
|
|
You then simply run make. It will use this configuration file to retrieve,
|
|
extract and patch the components, build, install and test your newly built
|
|
toolchain.
|
|
|
|
You are then free to add the toolchain /bin directory in your PATH to use
|
|
it at will.
|
|
|
|
_____________
|
|
/
|
|
Internals /
|
|
__________/
|
|
|
|
<To be completed>
|