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