path: root/docs
diff options
authorYann E. MORIN" <>2007-02-24 11:00:05 (GMT)
committerYann E. MORIN" <>2007-02-24 11:00:05 (GMT)
commit1906cf93f86d8d66f45f90380a8d3da25c087ee5 (patch)
tree90916c99abe1f1ec26709ee420e6c349eda4670a /docs
parent2609573aede4ce198b3462976725b25eb1637d2e (diff)
Add the full crosstool-NG sources to the new repository of its own.
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... :-(
Diffstat (limited to 'docs')
1 files changed, 108 insertions, 0 deletions
diff --git a/docs/overview.txt b/docs/overview.txt
new file mode 100644
index 0000000..8027180
--- /dev/null
+++ b/docs/overview.txt
@@ -0,0 +1,108 @@
+File.........: overview.txt
+Content......: Overview of how ct-ng works.
+Copyrigth....: (C) 2006 Yann E. MORIN <>
+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 ( 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 (, whose purpose is very
+ similar to buildroot,
+ - other projects ( 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, and the subversion repository is hosted on google at
+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
+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
+You are then free to add the toolchain /bin directory in your PATH to use
+it at will.
+ /
+Internals /
+<To be completed>