path: root/docs/1 - Introduction.txt
diff options
authorYann E. MORIN" <>2010-08-14 14:37:11 (GMT)
committerYann E. MORIN" <>2010-08-14 14:37:11 (GMT)
commita211f4100d3e0196807dbd3b4f1839c41f79f5b1 (patch)
treed29a9ed57c0946e22afaed850658e4075c6ab1d9 /docs/1 - Introduction.txt
parentebaebdacf45166a587e4e4d2d5e7b2f7a08965e2 (diff)
docs: split into multiple files
The overview.txt file has evolved into more than just an overview. Split it into chapters, and include the misc tutorials. Signed-off-by: "Yann E. MORIN" <>
Diffstat (limited to 'docs/1 - Introduction.txt')
-rw-r--r--docs/1 - Introduction.txt108
1 files changed, 108 insertions, 0 deletions
diff --git a/docs/1 - Introduction.txt b/docs/1 - Introduction.txt
new file mode 100644
index 0000000..085b034
--- /dev/null
+++ b/docs/1 - Introduction.txt
@@ -0,0 +1,108 @@
+File.........: 1 - Introduction.txt
+Copyrigth....: (C) 2010 Yann E. MORIN <>
+License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
+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 developed. 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 regrettable).
+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 become quite a nightmare...
+Some cross-toolchains exist 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 aging 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 build toolchains for specific needs,
+which are not really scalable. Examples are:
+ - buildroot ( whose main purpose 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 are again used to
+ build root file systems.
+crosstool-NG is really targeted 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, who 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
+I once managed to add support for uClibc-based toolchains, but it did not make
+into mainline, mostly because I didn'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, add appropriate support for what I needed, that is uClibc support
+and a menu-driven configuration, named the new implementation crosstool-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" ;-) ) and
+made it available to the community, in case it was of interest to any one.
+Referring to crosstool-NG |
+The long name of the project is crosstool-NG:
+ * no leading uppercase (except as first word in a sentence)
+ * crosstool and NG separated with a hyphen (dash)
+ * NG in uppercase
+Crosstool-NG can also be referred to by its short name CT-NG:
+ * all in uppercase
+ * CT and NG separated with a hyphen (dash)
+The long name is preferred over the short name, except in mail subjects, where
+the short name is a better fit.
+When referring to a specific version of crosstool-NG, append the version number
+either as:
+ * crosstool-NG X.Y.Z
+ - the long name, a space, and the version string
+ * crosstool-ng-X.Y.Z
+ - the long name in lowercase, a hyphen (dash), and the version string
+ - this is used to name the release tarballs
+ * crosstool-ng-X.Y.Z+hg_id
+ - the long name in lowercase, a hyphen, the version string, and the Hg id
+ (as returned by: ct-ng version)
+ - this is used to differentiate between releases and snapshots
+The frontend to crosstool-NG is the command ct-ng:
+ * all in lowercase
+ * ct and ng separated by a hyphen (dash)