docs/1 - Introduction.txt
author "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Mon Apr 16 15:25:36 2012 +0200 (2012-04-16)
changeset 2941 13e40098fffc
parent 2564 5d4e91c0343e
permissions -rw-r--r--
cc/gcc: update Linaro GCC revisions to 2012.04

Update Linaro GCC with the latest available revisions.

The 4.7 revision is also released, but the infrastructure is not yet ready for
it in CT-NG.

Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
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)