yann@2076
|
1 |
File.........: 1 - Introduction.txt
|
yann@2908
|
2 |
Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@free.fr>
|
yann@2076
|
3 |
License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
|
yann@2076
|
4 |
|
yann@2076
|
5 |
|
yann@2076
|
6 |
Introduction /
|
yann@2076
|
7 |
_____________/
|
yann@2076
|
8 |
|
yann@2076
|
9 |
|
yann@2076
|
10 |
crosstool-NG aims at building toolchains. Toolchains are an essential component
|
yann@2076
|
11 |
in a software development project. It will compile, assemble and link the code
|
yann@2076
|
12 |
that is being developed. Some pieces of the toolchain will eventually end up
|
yann@2076
|
13 |
in the resulting binary/ies: static libraries are but an example.
|
yann@2076
|
14 |
|
yann@2076
|
15 |
So, a toolchain is a very sensitive piece of software, as any bug in one of the
|
yann@2076
|
16 |
components, or a poorly configured component, can lead to execution problems,
|
yann@2076
|
17 |
ranging from poor performance, to applications ending unexpectedly, to
|
yann@2076
|
18 |
mis-behaving software (which more than often is hard to detect), to hardware
|
yann@2076
|
19 |
damage, or even to human risks (which is more than regrettable).
|
yann@2076
|
20 |
|
yann@2076
|
21 |
Toolchains are made of different piece of software, each being quite complex
|
yann@2076
|
22 |
and requiring specially crafted options to build and work seamlessly. This
|
yann@2076
|
23 |
is usually not that easy, even in the not-so-trivial case of native toolchains.
|
yann@2076
|
24 |
The work reaches a higher degree of complexity when it comes to cross-
|
yann@2076
|
25 |
compilation, where it can become quite a nightmare...
|
yann@2076
|
26 |
|
yann@2076
|
27 |
Some cross-toolchains exist on the internet, and can be used for general
|
yann@2076
|
28 |
development, but they have a number of limitations:
|
yann@2076
|
29 |
- they can be general purpose, in that they are configured for the majority:
|
yann@2076
|
30 |
no optimisation for your specific target,
|
yann@2076
|
31 |
- they can be prepared for a specific target and thus are not easy to use,
|
yann@2076
|
32 |
nor optimised for, or even supporting your target,
|
yann@2076
|
33 |
- they often are using aging components (compiler, C library, etc...) not
|
yann@2076
|
34 |
supporting special features of your shiny new processor;
|
yann@2076
|
35 |
On the other side, these toolchain offer some advantages:
|
yann@2076
|
36 |
- they are ready to use and quite easy to install and setup,
|
yann@2076
|
37 |
- they are proven if used by a wide community.
|
yann@2076
|
38 |
|
yann@2076
|
39 |
But once you want to get all the juice out of your specific hardware, you will
|
yann@2076
|
40 |
want to build your own toolchain. This is where crosstool-NG comes into play.
|
yann@2076
|
41 |
|
yann@2076
|
42 |
There are also a number of tools that build toolchains for specific needs,
|
yann@2076
|
43 |
which are not really scalable. Examples are:
|
yann@2076
|
44 |
- buildroot (buildroot.uclibc.org) whose main purpose is to build root file
|
yann@2076
|
45 |
systems, hence the name. But once you have your toolchain with buildroot,
|
yann@2076
|
46 |
part of it is installed in the root-to-be, so if you want to build a whole
|
yann@2076
|
47 |
new root, you either have to save the existing one as a template and
|
yann@2076
|
48 |
restore it later, or restart again from scratch. This is not convenient,
|
yann@2076
|
49 |
- ptxdist (www.pengutronix.de/software/ptxdist), whose purpose is very
|
yann@2076
|
50 |
similar to buildroot,
|
yann@2076
|
51 |
- other projects (openembedded.org for example), which are again used to
|
yann@2076
|
52 |
build root file systems.
|
yann@2076
|
53 |
|
yann@2076
|
54 |
crosstool-NG is really targeted at building toolchains, and only toolchains.
|
yann@2076
|
55 |
It is then up to you to use it the way you want.
|
yann@2076
|
56 |
|
yann@2076
|
57 |
|
yann@2076
|
58 |
History |
|
yann@2076
|
59 |
--------+
|
yann@2076
|
60 |
|
yann@2076
|
61 |
crosstool was first 'conceived' by Dan Kegel, who offered it to the community
|
yann@2076
|
62 |
as a set of scripts, a repository of patches, and some pre-configured, general
|
yann@2076
|
63 |
purpose setup files to be used to configure crosstool. This is available at
|
yann@2076
|
64 |
http://www.kegel.com/crosstool, and the subversion repository is hosted on
|
yann@2076
|
65 |
google at http://code.google.com/p/crosstool/.
|
yann@2076
|
66 |
|
yann@2076
|
67 |
I once managed to add support for uClibc-based toolchains, but it did not make
|
yann@2076
|
68 |
into mainline, mostly because I didn't have time to port the patch forward to
|
yann@2076
|
69 |
the new versions, due in part to the big effort it was taking.
|
yann@2076
|
70 |
|
yann@2076
|
71 |
So I decided to clean up crosstool in the state it was, re-order the things
|
yann@2076
|
72 |
in place, add appropriate support for what I needed, that is uClibc support
|
yann@2076
|
73 |
and a menu-driven configuration, named the new implementation crosstool-NG,
|
antony@2564
|
74 |
(standing for crosstool Next Generation, as many other community projects do,
|
yann@2076
|
75 |
and as a wink at the TV series "Star Trek: The Next Generation" ;-) ) and
|
yann@2076
|
76 |
made it available to the community, in case it was of interest to any one.
|
yann@2076
|
77 |
|
yann@2076
|
78 |
|
yann@2076
|
79 |
Referring to crosstool-NG |
|
yann@2076
|
80 |
--------------------------+
|
yann@2076
|
81 |
|
yann@2076
|
82 |
The long name of the project is crosstool-NG:
|
yann@2076
|
83 |
* no leading uppercase (except as first word in a sentence)
|
yann@2076
|
84 |
* crosstool and NG separated with a hyphen (dash)
|
yann@2076
|
85 |
* NG in uppercase
|
yann@2076
|
86 |
|
yann@2076
|
87 |
Crosstool-NG can also be referred to by its short name CT-NG:
|
yann@2076
|
88 |
* all in uppercase
|
yann@2076
|
89 |
* CT and NG separated with a hyphen (dash)
|
yann@2076
|
90 |
|
yann@2076
|
91 |
The long name is preferred over the short name, except in mail subjects, where
|
yann@2076
|
92 |
the short name is a better fit.
|
yann@2076
|
93 |
|
yann@2076
|
94 |
When referring to a specific version of crosstool-NG, append the version number
|
yann@2076
|
95 |
either as:
|
yann@2076
|
96 |
* crosstool-NG X.Y.Z
|
yann@2076
|
97 |
- the long name, a space, and the version string
|
yann@2076
|
98 |
* crosstool-ng-X.Y.Z
|
yann@2076
|
99 |
- the long name in lowercase, a hyphen (dash), and the version string
|
yann@2076
|
100 |
- this is used to name the release tarballs
|
yann@2076
|
101 |
* crosstool-ng-X.Y.Z+hg_id
|
yann@2076
|
102 |
- the long name in lowercase, a hyphen, the version string, and the Hg id
|
yann@2076
|
103 |
(as returned by: ct-ng version)
|
yann@2076
|
104 |
- this is used to differentiate between releases and snapshots
|
yann@2076
|
105 |
|
yann@2076
|
106 |
The frontend to crosstool-NG is the command ct-ng:
|
yann@2076
|
107 |
* all in lowercase
|
yann@2076
|
108 |
* ct and ng separated by a hyphen (dash)
|