yann@1: File.........: overview.txt yann@197: Content......: Overview of how crosstool-NG works. yann@92: Copyrigth....: (C) 2007 Yann E. MORIN yann@192: License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5 yann@92: yann@628: ____________________ yann@628: / yann@628: Table Of Content / yann@628: _________________/ yann@628: yann@628: yann@628: Introduction yann@628: History yann@1581: Referring to crosstool-NG yann@628: Installing crosstool-NG yann@628: Install method yann@628: The hacker's way yann@1048: Preparing for packaging yann@837: Shell completion yann@628: Contributed code yann@628: Configuring crosstool-NG yann@628: Interesting config options yann@628: Re-building an existing toolchain yann@1842: Using as a backend for a build-system yann@628: Running crosstool-NG yann@628: Stopping and restarting a build yann@628: Testing all toolchains at once yann@628: Overriding the number of // jobs yann@1491: Note on // jobs yann@1493: Tools wrapper yann@628: Using the toolchain yann@1554: The 'populate' script yann@628: Toolchain types yann@1551: Seemingly-native toolchains yann@1575: Contributing yann@1575: Sending a bug report yann@1575: Sending patches yann@628: Internals yann@628: Makefile front-end yann@628: Kconfig parser yann@628: Architecture-specific yann@628: Adding a new version of a component yann@628: Build scripts yann@628: yann@1580: 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 rpjday@436: that is being developed. 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 rpjday@436: damage, or even to human risks (which is more than regrettable). 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@40: compilation, where it can become quite a nightmare... yann@1: yann@40: Some cross-toolchains exist 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, rpjday@436: - they often are using aging 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@197: want to build your own toolchain. This is where crosstool-NG comes into play. yann@1: rpjday@436: There are also a number of tools that build toolchains for specific needs, rpjday@436: which are not really scalable. Examples are: rpjday@436: - buildroot (buildroot.uclibc.org) whose main purpose 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@702: - other projects (openembedded.org for example), which are again used to yann@1: build root file systems. yann@1: rpjday@436: crosstool-NG is really targeted at building toolchains, and only toolchains. yann@1: It is then up to you to use it the way you want. yann@1: yann@1580: yann@1: ___________ yann@1: / yann@1: History / yann@1: ________/ yann@1: rpjday@436: crosstool was first 'conceived' by Dan Kegel, who 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@203: http://www.kegel.com/crosstool, and the subversion repository is hosted on yann@203: google at http://code.google.com/p/crosstool/. yann@1: yann@1: I once managed to add support for uClibc-based toolchains, but it did not make yann@437: into mainline, mostly because I didn'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@437: in place, add appropriate support for what I needed, that is uClibc support yann@437: and a menu-driven configuration, named the new implementation crosstool-NG, yann@437: (standing for crosstool Next Generation, as many other comunity projects do, yann@437: and as a wink at the TV series "Star Trek: The Next Generation" ;-) ) and yann@437: made it available to the community, in case it was of interest to any one. yann@1: yann@1580: yann@1581: _____________________________ yann@1581: / yann@1581: Referring to crosstool-NG / yann@1581: __________________________/ yann@1581: yann@1581: yann@1581: The long name of the project is crosstool-NG: yann@1581: * no leading uppercase (except as first word in a sentence) yann@1581: * crosstool and NG separated with a hyphen (dash) yann@1581: * NG in uppercase yann@1581: yann@1581: Crosstool-NG can also be referred to by its short name CT-NG: yann@1581: * all in uppercase yann@1581: * CT and NG separated with a hyphen (dash) yann@1581: yann@1581: The long name is preferred over the short name, except in mail subjects, where yann@1581: the short name is a better fit. yann@1581: yann@1581: When referring to a specific version of crosstool-NG, append the version number yann@1581: either as: yann@1581: * crosstool-NG X.Y.Z yann@1581: - the long name, a space, and the version string yann@1581: * crosstool-ng-X.Y.Z yann@1581: - the long name in lowercase, a hyphen (dash), and the version string yann@1581: - this is used to name the release tarballs yann@1581: * crosstool-ng-X.Y.Z+hg_id yann@1581: - the long name in lowercase, a hyphen, the version string, and the Hg id yann@1581: (as returned by: ct-ng version) yann@1581: - this is used to differentiate between releases and snapshots yann@1581: yann@1581: The frontend to crosstool-NG is the command ct-ng: yann@1581: * all in lowercase yann@1581: * ct and ng separated by a hyphen (dash) yann@1581: yann@1581: yann@294: ___________________________ yann@294: / yann@294: Installing crosstool-NG / yann@294: ________________________/ yann@294: yann@294: There are two ways you can use crosstool-NG: yann@294: - build and install it, then get rid of the sources like you'd do for most yann@294: programs, yann@294: - or only build it and run from the source directory. yann@294: yann@294: The former should be used if you got crosstool-NG from a packaged tarball, see rpjday@436: "Install method", below, while the latter is most useful for developpers that yann@1576: use a clone of the repository, and want to submit patches, see "The Hacker's yann@294: way", below. yann@294: yann@294: Install method | yann@294: ---------------+ yann@294: yann@294: If you go for the install, then you just follow the classical, but yet easy yann@294: ./configure way: yann@294: ./configure --prefix=/some/place yann@294: make yann@294: make install yann@294: export PATH="${PATH}:/some/place/bin" yann@294: yann@294: You can then get rid of crosstool-NG source. Next create a directory to serve yann@294: as a working place, cd in there and run: yann@294: ct-ng help yann@294: yann@294: See below for complete usage. yann@294: yann@294: The Hacker's way | yann@294: -----------------+ yann@294: yann@294: If you go the hacker's way, then the usage is a bit different, although very yann@294: simple: yann@294: ./configure --local yann@294: make yann@294: yann@294: Now, *do not* remove crosstool-NG sources. They are needed to run crosstool-NG! yann@294: Stay in the directory holding the sources, and run: yann@294: ./ct-ng help yann@294: yann@294: See below for complete usage. yann@294: yann@1554: Now, provided you used a clone of the repository, you can send me your changes. yann@1575: See the section titled CONTRIBUTING, below, for how to submit changees. yann@294: yann@1048: Preparing for packaging | yann@1048: ------------------------+ yann@1048: yann@1048: If you plan on packaging crosstool-NG, you surely don't want to install it yann@1048: in your root file system. The install procedure of crosstool-NG honors the yann@1048: DESTDIR variable: yann@1048: yann@1048: ./configure --prefix=/usr yann@1048: make rpjday@1291: make DESTDIR=/packaging/place install yann@1048: yann@837: Shell completion | yann@837: -----------------+ yann@837: yann@837: crosstool-NG comes with a shell script fragment that defines bash-compatible yann@837: completion. That shell fragment is currently not installed automatically, but yann@837: this is planned. yann@837: yann@837: To install the shell script fragment, you have two options: yann@837: - install system-wide, most probably by copying ct-ng.comp into yann@837: /etc/bash_completion.d/ yann@837: - install for a single user, by copying ct-ng.comp into ${HOME}/ and yann@837: sourcing this file from your ${HOME}/.bashrc yann@837: yann@456: Contributed code | yann@456: -----------------+ yann@456: yann@456: Some people contibuted code that couldn't get merged for various reasons. This yann@1574: code is available as lzma-compressed patches, in the contrib/ sub-directory. yann@1574: These patches are to be applied to the source of crosstool-NG, prior to yann@1574: installing, using something like the following: yann@1574: lzcat contrib/foobar.patch.lzma |patch -p1 yann@620: yann@620: There is no guarantee that a particuliar contribution applies to the current yann@620: version of crosstool-ng, or that it will work at all. Use contributions at yann@620: your own risk. yann@620: yann@1580: yann@168: ____________________________ yann@168: / yann@168: Configuring crosstool-NG / yann@168: _________________________/ yann@168: yann@620: crosstool-NG is configured with a configurator presenting a menu-stuctured set yann@620: of options. These options let you specify the way you want your toolchain yann@620: built, where you want it installed, what architecture and specific processor it yann@277: will support, the version of the components you want to use, etc... The yann@277: value for those options are then stored in a configuration file. yann@277: yann@476: The configurator works the same way you configure your Linux kernel. It is yann@277: assumed you now how to handle this. yann@168: yann@168: To enter the menu, type: yann@192: ct-ng menuconfig yann@168: yann@203: Almost every config item has a help entry. Read them carefully. yann@168: yann@168: String and number options can refer to environment variables. In such a case, yann@192: you must use the shell syntax: ${VAR}. You shall neither single- nor double- yann@294: quote the string/number options. yann@168: yann@192: There are three environment variables that are computed by crosstool-NG, and yann@168: that you can use: yann@168: yann@168: CT_TARGET: yann@335: It represents the target tuple you are building for. You can use it for yann@168: example in the installation/prefix directory, such as: yann@168: /opt/x-tools/${CT_TARGET} yann@168: yann@168: CT_TOP_DIR: yann@182: The top directory where crosstool-NG is running. You shouldn't need it in yann@182: most cases. There is one case where you may need it: if you have local yann@182: patches and you store them in your running directory, you can refer to them yann@168: by using CT_TOP_DIR, such as: yann@168: ${CT_TOP_DIR}/patches.myproject yann@168: yann@168: CT_VERSION: yann@192: The version of crosstool-NG you are using. Not much use for you, but it's yann@168: there if you need it. yann@168: yann@168: Interesting config options | yann@476: ---------------------------+ yann@168: yann@168: CT_LOCAL_TARBALLS_DIR: yann@277: If you already have some tarballs in a direcotry, enter it here. That will yann@197: speed up the retrieving phase, where crosstool-NG would otherwise download yann@168: those tarballs. yann@168: yann@168: CT_PREFIX_DIR: yann@168: This is where the toolchain will be installed in (and for now, where it yann@437: will run from). Common use is to add the target tuple in the directory yann@277: path, such as (see above): yann@277: /opt/x-tools/${CT_TARGET} yann@168: yann@168: CT_TARGET_VENDOR: yann@168: An identifier for your toolchain, will take place in the vendor part of the yann@335: target tuple. It shall *not* contain spaces or dashes. Usually, keep it yann@168: to a one-word string, or use underscores to separate words if you need. yann@168: Avoid dots, commas, and special characters. yann@168: yann@168: CT_TARGET_ALIAS: yann@168: An alias for the toolchian. It will be used as a prefix to the toolchain yann@168: tools. For example, you will have ${CT_TARGET_ALIAS}-gcc yann@168: yann@246: Also, if you think you don't see enough versions, you can try to enable one of yann@246: those: yann@246: yann@246: CT_OBSOLETE: yann@246: Show obsolete versions or tools. Most of the time, you don't want to base yann@246: your toolchain on too old a version (of gcc, for example). But at times, it yann@246: can come handy to use such an old version for regression tests. Those old yann@1300: versions are hidden behind CT_OBSOLETE. Those versions (or features) are so yann@1300: marked because maintaining support for those in crosstool-NG would be too yann@1300: costly, time-wise, and time is dear. yann@246: yann@246: CT_EXPERIMENTAL: yann@246: Show experimental versions or tools. Again, you might not want to base your yann@246: toolchain on too recent tools (eg. gcc) for production. But if you need a yann@246: feature present only in a recent version, or a new tool, you can find them yann@1300: hidden behind CT_EXPERIMENTAL. Those versions (or features) did not (yet) yann@1300: receive thorough testing in crosstool-NG, and/or are not mature enough to yann@1300: be blindly trusted. yann@246: yann@276: Re-building an existing toolchain | yann@276: ----------------------------------+ yann@276: yann@276: If you have an existing toolchain, you can re-use the options used to build it yann@276: to create a new toolchain. That needs a very little bit of effort on your side yann@894: but is quite easy. The options to build a toolchain are saved with the yann@894: toolchain, and you can retrieve this configuration by running: yann@1803: ${CT_TARGET}-ct-ng.config yann@276: yann@1803: An alternate method is to extract the configuration from a build.log file. yann@1803: This will be necessary if your toolchain was build with crosstool-NG prior yann@1803: to 1.4.0, but can be used with build.log files from any version: yann@1803: ct-ng extractconfig .config yann@1803: yann@1803: Or, if your build.log file is compressed (most probably!): yann@1803: bzcat build.log.bz2 |ct-ng extractconfig >.config yann@1803: yann@1803: The above commands will dump the configuration to stdout, so to rebuild a yann@1803: toolchain with this configuration, just redirect the output to the yann@1803: .config file: yann@1803: ${CT_TARGET}-ct-ng.config >.config yann@1098: ct-ng oldconfig yann@276: yann@894: Then, you can review and change the configuration by running: yann@894: ct-ng menuconfig yann@276: yann@1842: Using as a backend for a build-system | yann@1842: --------------------------------------+ yann@1842: yann@1842: Crosstool-NG can be used as a backend for an automated build-system. In this yann@1842: case, some components that are expected to run on the target (eg. the native yann@1842: gdb, ltrace, DUMA...) are not available in the menuconfig, and they are not yann@1842: build either, as it is considered the responsibility of the build-system to yann@1842: build its own versions of those tools. yann@1842: yann@1842: If you want to use crosstool-NG as a backend to generate your toolchains for yann@1842: your build-system, you have to set and export this environment variable: yann@1842: CT_IS_A_BACKEND=y yann@1842: yann@1842: (case is not sensitive, you can say Y). yann@1842: yann@1580: yann@168: ________________________ yann@168: / yann@168: Running crosstool-NG / yann@168: _____________________/ yann@1: yann@168: To build the toolchain, simply type: yann@203: ct-ng build yann@135: yann@135: This will use the above configuration to retrieve, extract and patch the yann@135: components, build, install and eventually test your newly built 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@135: In any case, you can get some terse help. Just type: yann@192: ct-ng help yann@203: or: yann@203: man 1 ct-ng yann@135: rpjday@436: Stopping and restarting a build | yann@476: --------------------------------+ yann@135: yann@135: If you want to stop the build after a step you are debugging, you can pass the yann@135: variable STOP to make: fr@1643: ct-ng build STOP=some_step yann@135: yann@135: Conversely, if you want to restart a build at a specific step you are yann@135: debugging, you can pass the RESTART variable to make: fr@1643: ct-ng build RESTART=some_step yann@135: yann@136: Alternatively, you can call make with the name of a step to just do that step: yann@192: ct-ng libc_headers yann@136: is equivalent to: fr@1643: ct-ng build RESTART=libc_headers STOP=libc_headers yann@136: yann@304: The shortcuts +step_name and step_name+ allow to respectively stop or restart yann@136: at that step. Thus: fr@1643: ct-ng +libc_headers and: ct-ng libc_headers+ yann@136: are equivalent to: fr@1643: ct-ng build STOP=libc_headers and: ct-ng build RESTART=libc_headers yann@136: yann@181: To obtain the list of acceptable steps, please call: yann@544: ct-ng list-steps yann@181: yann@168: Note that in order to restart a build, you'll have to say 'Y' to the config yann@168: option CT_DEBUG_CT_SAVE_STEPS, and that the previous build effectively went yann@168: that far. yann@92: yann@1025: Building all toolchains at once | yann@1025: --------------------------------+ yann@92: yann@1025: You can build all samples; simply call: yann@1025: ct-ng build-all yann@40: yann@335: Overriding the number of // jobs | yann@476: ---------------------------------+ yann@335: yann@335: If you want to override the number of jobs to run in // (the -j option to yann@335: make), you can either re-enter the menuconfig, or simply add it on the command yann@335: line, as such: yann@335: ct-ng build.4 yann@335: yann@335: which tells crosstool-NG to override the number of // jobs to 4. yann@335: yann@335: You can see the actions that support overriding the number of // jobs in yann@335: the help menu. Those are the ones with [.#] after them (eg. build[.#] or yann@1025: build-all[.#], and so on...). yann@1025: yann@1025: Note on // jobs | yann@1025: ----------------+ yann@1025: yann@1025: The crosstool-NG script 'ct-ng' is a Makefile-script. It does *not* execute yann@1025: in parallel (there is not much to gain). When speaking of // jobs, we are yann@1025: refering to the number of // jobs when making the *components*. That is, we yann@1025: speak of the number of // jobs used to build gcc, glibc, and so on... yann@1025: yann@1493: Tools wrapper | yann@1493: --------------+ yann@1493: yann@1493: Starting with gcc-4.3 come two new dependencies: GMP and MPFR. With gcc-4.4, yann@1937: come three new ones: PPL, CLooG/ppl and MPC. With gcc-4.5 again comes a new yann@1937: dependency on libelf. These are libraries that enable advanced features to yann@1937: gcc. Additionally, some of those libraries can be used by binutils and gdb. yann@1937: Unfortunately, not all systems on which crosstool-NG runs have all of those yann@1937: libraries. And for those that do, the versions of those libraries may be yann@1937: older than the version required by gcc (and binutils and gdb). To date, yann@1937: Debian stable (aka Lenny) is lagging behind on some, and is missing the yann@1937: others. yann@1493: yann@1493: This is why crosstool-NG builds its own set of libraries as part of the yann@1493: toolchain. yann@1493: yann@1937: The companion libraries can be built either as static libraries, or as shared yann@1937: libraries. The default is to build static libraries, and is the safe way. yann@1937: If you decide to use static companion libraries, then you can stop reading yann@1937: this section. yann@1937: yann@1937: But if you prefer to have shared libraries, then read on... yann@1937: yann@1937: Building shared companion libraries poses no problem at build time, as yann@1513: crosstool-NG correctly points gcc (and binutils and gdb) to the correct yann@1493: place where our own version of the libraries are installed. But it poses yann@1493: a problem when gcc et al. are run: the place where the libraries are is most yann@1493: probably not known to the host dynamic linker. Still worse, if the host system yann@1937: has its own versions, then ld.so would load the wrong libraries! yann@1493: yann@1493: So we have to force the dynamic linker to load the correct version. We do this yann@1493: by using the LD_LIBRARY_PATH variable, that informs the dynamic linker where yann@1493: to look for shared libraries prior to searching its standard places. But we yann@1493: can't impose that burden on all the system (because it'd be a nightmare to yann@1513: configure, and because two toolchains on the same system may use different yann@1493: versions of the libraries); so we have to do it on a per-toolchain basis. yann@1493: yann@1493: So we rename all binaries of the toolchain (by adding a dot '.' as their first yann@1493: character), and add a small program, the so-called "tools wrapper", that yann@1493: correctly sets LD_LIBRARY_PATH prior to running the real tool. yann@1493: yann@1493: First, the wrapper was written as a POSIX-compliant shell script. That shell yann@1493: script is very simple, if not trivial, and works great. The only drawback is yann@1493: that it does not work on host systems that lack a shell, for example the yann@1493: MingW32 environment. To solve the issue, the wrapper has been re-written in C, yann@1493: and compiled at build time. This C wrapper is much more complex than the shell yann@1493: script, and although it sems to be working, it's been only lightly tested. yann@1493: Some of the expected short-comings with this C wrapper are; yann@1493: - multi-byte file names may not be handled correctly yann@1493: - it's really big for what it does yann@1493: yann@1493: So, the default wrapper installed with your toolchain is the shell script. yann@1493: If you know that your system is missing a shell, then you shall use the C yann@1493: wrapper (and report back whether it works, or does not work, for you). yann@1493: yann@1937: A final word on the subject: do not build shared libraries. Build them yann@1937: static, and you'll be safe. yann@1937: yann@335: yann@227: _______________________ yann@227: / yann@227: Using the toolchain / yann@227: ____________________/ yann@227: yann@227: Using the toolchain is as simple as adding the toolchain's bin directory in yann@227: your PATH, such as: yann@227: export PATH="${PATH}:/your/toolchain/path/bin" yann@227: yann@335: and then using the target tuple to tell the build systems to use your yann@227: toolchain: yann@335: ./configure --target=your-target-tuple yann@294: or yann@335: make CC=your-target-tuple-gcc yann@294: or yann@335: make CROSS_COMPILE=your-target-tuple- yann@294: and so on... yann@227: yann@476: It is strongly advised not to use the toolchain sys-root directory as an yann@620: install directory for your programs/packages. If you do so, you will not be yann@476: able to use your toolchain for another project. It is even strongly advised yann@476: that your toolchain is chmod-ed to read-only once successfully build, so that yann@620: you don't go polluting your toolchain with your programs/packages' files. yann@476: yann@476: Thus, when you build a program/package, install it in a separate directory, yann@476: eg. /your/root. This directory is the /image/ of what would be in the root file yann@620: system of your target, and will contain all that your programs/packages have yann@476: installed. yann@476: Yann@1405: The 'populate' script | Yann@1405: ----------------------+ Yann@1405: yann@227: When your root directory is ready, it is still missing some important bits: the yann@227: toolchain's libraries. To populate your root directory with those libs, just yann@227: run: yann@335: your-target-tuple-populate -s /your/root -d /your/root-populated yann@227: yann@227: This will copy /your/root into /your/root-populated, and put the needed and only yann@227: the needed libraries there. Thus you don't polute /your/root with any cruft that yann@227: would no longer be needed should you have to remove stuff. /your/root always yann@227: contains only those things you install in it. yann@227: yann@227: You can then use /your/root-populated to build up your file system image, a yann@227: tarball, or to NFS-mount it from your target, or whatever you need. yann@227: Yann@1405: The populate script accepts the following options: yann@294: Yann@1405: -s src_dir Yann@1405: Use 'src_dir' as the un-populated root directory. yann@294: Yann@1405: -d dst_dir Yann@1405: Put the populated root directory in 'dst_dir'. Yann@1405: Yann@1405: -l lib1 [...] Yann@1405: Always add specified libraries. Yann@1405: Yann@1405: -L file Yann@1405: Always add libraries listed in 'file'. yann@294: yann@294: -f Yann@1405: Remove 'dst_dir' if it previously existed; continue even if any library Yann@1405: specified with -l or -L is missing. yann@294: yann@294: -v yann@294: Be verbose, and tell what's going on (you can see exactly where libs are yann@294: coming from). yann@294: yann@294: -h Yann@1405: Print the help. Yann@1405: Yann@1405: See 'your-target-tuple-populate -h' for more information on the options. yann@294: Yann@1406: Here is how populate works: Yann@1406: Yann@1406: 1) performs some sanity checks: Yann@1406: - src_dir and dst_dir are specified Yann@1406: - src_dir exists Yann@1406: - unless forced, dst_dir does not exist Yann@1406: - src_dir != dst_dir Yann@1406: Yann@1406: 2) copy src_dir to dst_dir Yann@1406: Yann@1406: 3) add forced libraries to dst_dir Yann@1406: - build the list from -l and -L options Yann@1406: - get forced libraries from the sysroot (see below for heuristics) Yann@1406: - abort on the first missing library, unless -f is specified Yann@1406: Yann@1406: 4) add all missing libraries to dst_dir Yann@1406: - scan dst_dir for every ELF files that are 'executable' or Yann@1406: 'shared object' Yann@1406: - list the "NEEDED Shared library" fields Yann@1406: - check if the library is already in dst_dir/lib or dst_dir/usr/lib Yann@1406: - if not, get the library from the sysroot Yann@1406: - if it's in sysroot/lib, copy it to dst_dir/lib Yann@1406: - if it's in sysroot/usr/lib, copy it to dst_dir/usr/lib Yann@1406: - in both cases, use the SONAME of the library to create the file Yann@1406: in dst_dir Yann@1406: - if it was not found in the sysroot, this is an error. Yann@1406: yann@1580: yann@40: ___________________ yann@40: / yann@40: Toolchain types / yann@40: ________________/ yann@40: yann@40: There are four kinds of toolchains you could encounter. yann@40: yann@40: First off, you must understand the following: when it comes to compilers there yann@40: are up to four machines involved: yann@40: 1) the machine configuring the toolchain components: the config machine yann@40: 2) the machine building the toolchain components: the build machine yann@40: 3) the machine running the toolchain: the host machine yann@203: 4) the machine the toolchain is generating code for: the target machine yann@40: yann@40: We can most of the time assume that the config machine and the build machine yann@40: are the same. Most of the time, this will be true. The only time it isn't yann@40: is if you're using distributed compilation (such as distcc). Let's forget yann@40: this for the sake of simplicity. yann@40: yann@40: So we're left with three machines: yann@40: - build yann@40: - host yann@40: - target yann@40: yann@40: Any toolchain will involve those three machines. You can be as pretty sure of yann@40: this as "2 and 2 are 4". Here is how they come into play: yann@40: yann@40: 1) build == host == target yann@40: This is a plain native toolchain, targetting the exact same machine as the yann@40: one it is built on, and running again on this exact same machine. You have yann@40: to build such a toolchain when you want to use an updated component, such yann@40: as a newer gcc for example. yann@197: crosstool-NG calls it "native". yann@40: yann@40: 2) build == host != target yann@40: This is a classic cross-toolchain, which is expected to be run on the same yann@40: machine it is compiled on, and generate code to run on a second machine, yann@40: the target. yann@197: crosstool-NG calls it "cross". yann@40: yann@40: 3) build != host == target yann@40: Such a toolchain is also a native toolchain, as it targets the same machine yann@40: as it runs on. But it is build on another machine. You want such a yann@40: toolchain when porting to a new architecture, or if the build machine is yann@40: much faster than the host machine. yann@197: crosstool-NG calls it "cross-native". yann@40: yann@40: 4) build != host != target yann@92: This one is called a canadian-toolchain (*), and is tricky. The three yann@40: machines in play are different. You might want such a toolchain if you yann@40: have a fast build machine, but the users will use it on another machine, yann@40: and will produce code to run on a third machine. yann@197: crosstool-NG calls it "canadian". yann@40: yann@197: crosstool-NG can build all these kinds of toolchains (or is aiming at it, yann@197: anyway!) yann@40: yann@40: (*) The term Canadian Cross came about because at the time that these issues yann@40: were all being hashed out, Canada had three national political parties. yann@40: http://en.wikipedia.org/wiki/Cross_compiler yann@40: yann@1551: yann@1575: ________________ yann@1575: / yann@1575: Contributing / yann@1575: _____________/ yann@1575: yann@1575: Sending a bug report | yann@1575: ---------------------+ yann@1575: yann@1575: If you need to send a bug report, please send a mail with subject yann@1575: prefixed with "[CT_NG]" with to following destinations: yann@1575: TO: yann.morin.1998 (at) anciens.enib.fr yann@1575: CC: crossgcc (at) sourceware.org yann@1575: yann@1575: Sending patches | yann@1575: ----------------+ yann@1575: yann@1575: If you want to enhance crosstool-NG, there's a to-do list in the TODO file. yann@1575: yann@1575: Patches should come with the appropriate SoB line. A SoB line is typically yann@1575: something like: yann@1575: Signed-off-by: John DOE yann@1575: yann@1575: The SoB line is clearly described in Documentation/SubmittingPatches , section yann@1575: 12, of your favourite Linux kernel source tree. yann@1575: titus@1963: titus@1963: How to Use Mercurial | titus@1963: ---------------------+ titus@1963: titus@1963: For larger or more frequent contributions, mercurial should be used. titus@1963: titus@1963: PREREQUISITES: titus@1963: titus@1963: Configuring Mercurial: titus@1963: You need mercurial with the following extensions: titus@1963: - mq : http://mercurial.selenic.com/wiki/MqExtension titus@1963: - patchbomb : http://mercurial.selenic.com/wiki/PatchbombExtension titus@1963: Usually, these two extensions are already part of the installation package. titus@1963: The mq extension maintains a separate queue of your local changes titus@1963: that you can change at any later time. titus@1963: With the patchbomb extension you can email those patches directly titus@1963: from your local repo. titus@1963: titus@1963: Your configuration file for mercurial, e.g. ~/.hgrc should contain titus@1963: at least the following sections (but have a look at `man hgrc`): titus@1963: # --- titus@1963: [email] titus@1963: # configure sending patches directly via Mercurial titus@1963: from = "Your Name" titus@1963: # How to send email: titus@1963: method = smtp titus@1963: titus@1963: [smtp] titus@1963: # SMTP configuration (only for method=smtp) titus@1963: host = localhost titus@1963: tls = true titus@1963: username = titus@1963: password = titus@1963: titus@1963: [extensions] titus@1963: # The following lines enable the two extensions: titus@1963: hgext.mq = titus@1963: hgext.patchbomb = titus@1963: # ---- titus@1963: titus@1963: Create your local repository as a clone: titus@1963: hg clone http://ymorin.is-a-geek.org/hg/crosstool-ng crosstool-ng titus@1963: titus@1963: Setting up the mq extension in your local copy: titus@1963: cd crosstool-ng titus@1963: hg qinit titus@1963: titus@1963: titus@1963: CREATING PATCHES: titus@1963: titus@1963: Recording your changes in the patch queue maintained by mq: titus@1963: # First, create a new patch entry in the patch queue: titus@1963: hg qnew -D -U -e short_patch_name1 titus@1963: titus@1963: titus@1963: titus@1963: titus@1963: # if you execute `hg status` here, your modifications of the working titus@1963: # copy should show up. titus@1963: titus@1963: # Now the following command takes your modifications from the working copy titus@1963: # into the patch entry titus@1963: hg qrefresh -D [-e] titus@1963: titus@1963: titus@1963: # Now your changes are recorded, and `hg status` should show a clean titus@1963: # working copy titus@1963: titus@1963: Repeat the above steps for all your modifications. titus@1963: The command `hg qseries` informs you about the content of your patch queue. titus@1963: titus@1963: titus@1963: CONTRIBUTING YOUR PATCHES: titus@1963: titus@1963: Once you are satisfied with your patch series, you can (you should!) titus@1963: contribute them back to upstream. titus@1963: This is easily done using the `hg email` command. titus@1963: titus@1963: `hg email` sends your new changesets to a specified list of recipients, titus@1963: each patch in its own email, all ordered in the way you entered them (oldest titus@1963: first). The command line flag --outgoing selects all changesets that are in titus@1963: your local but not yet in the upstream repository. Here, these are exactly titus@1963: the ones you entered into your local patch queue in the section above, so titus@1963: --outgoing is what you want. titus@1963: titus@1963: Each email gets the subject set to: "[PATCH x of n] " titus@1963: where 'x' is the serial number in the email series, and 'n' is the total number titus@1963: of patches in the series. The body of the email is the complete patch, plus titus@1963: a handful of metadata, that helps properly apply the patch, keeping the log titus@1963: message, attribution and date, tracking file changes (move, delete, modes...) titus@1963: titus@1963: `hg email` also threads all outgoing patch emails below an introductory titus@1963: message. You should use the introductory message (command line flag --intro) titus@1963: to describe the scope and motivation for the whole patch series. The subject titus@1963: for the introductory message gets set to: "[PATCH 0 of n] " titus@1963: and you get the chance to set the . titus@1963: titus@1963: Here is a sample `hg email` complete command line: titus@1963: Note: replace " (at) " with "@" titus@1963: titus@1963: hg email --outgoing --intro \ titus@1963: --to '"Yann E. MORIN" ' \ titus@1963: --cc 'crossgcc (at) sourceware.org' titus@1963: titus@1963: # It then opens an editor and lets you enter the subject titus@1963: # and the body for the introductory message. titus@1963: titus@1963: Use `hg email` with the additional command line switch -n to titus@1963: first have a look at the email(s) without actually sending them. titus@1963: titus@1963: titus@1963: MAINTAINING YOUR PATCHES: titus@1963: titus@1963: When the patches are refined by discussing them on the mailing list, titus@1963: you may want to finalize and resend them. titus@1963: titus@1963: The mq extension has the idiosyncrasy of imposing a stack onto the queue: titus@1963: You can always reedit/refresh only the patch on top of stack. titus@1963: The queue consists of applied and unapplied patches titus@1963: (if you reached here via the above steps, all of your patches are applied), titus@1963: where the 'stack' consists of the applied patches, and 'top of stack' titus@1963: is the latest applied patch. titus@1963: titus@1963: The following output of `hg qseries` is now used as an example: titus@1963: 0 A short_patch_name1 titus@1963: 1 A short_patch_name2 titus@1963: 2 A short_patch_name3 titus@1963: 3 A short_patch_name4 titus@1963: titus@1963: You are now able to edit patch 'short_patch_name4' (which is top of stack): titus@1963: titus@1963: # and execute again titus@1963: hg qrefresh -D [-e] titus@1963: titus@1963: titus@1963: If you want to edit e.g. patch short_patch_name2, you have to modify titus@1963: mq's stack so this patch gets top of stack. titus@1963: For this purpose see `hg help qgoto`, `hg help qpop`, and `hg help qpush`. titus@1963: titus@1963: hg qgoto short_patch_name2 titus@1963: # The patch queue should now look like titus@1963: hg qseries titus@1963: 0 A short_patch_name1 titus@1963: 1 A short_patch_name2 titus@1963: 2 U short_patch_name3 titus@1963: 3 U short_patch_name4 titus@1963: # so patch # 1 (short_patch_name2) is top of stack. titus@1963: titus@1963: # and execute again titus@1963: hg qrefresh -D [-e] titus@1963: titus@1963: # the following command reapplies the now unapplied two patches: titus@1963: hg qpush -a titus@1963: # you can also use `hg qgoto short_patch_name4` to get there again. titus@1963: titus@1963: titus@1963: RESENDING YOUR REEDITED PATCHES: titus@1963: titus@1963: By mailing list policy, please resend your complete patch series. titus@1963: --> Go back to section "CONTRIBUTING YOUR PATCHES" and resubmit the full set. titus@1963: titus@1963: titus@1963: SYNCING WITH UPSTREAM AGAIN: titus@1963: titus@1963: You can sync your repo with upstream at any time by executing titus@1963: # first unapply all your patches: titus@1963: hg qpop -a titus@1963: # next fetch new changesets from upstream titus@1963: hg pull titus@1963: # then update your working copy titus@1963: hg up titus@1963: # optionally remove already upstream integrated patches (see below) titus@1963: hg qdelete titus@1963: # and reapply your patches if any non upstream-integrated left (but see below) titus@1963: hg qpush -a titus@1963: titus@1963: Eventually, your patches get included into the upstream repository titus@1963: which you initially cloned. titus@1963: In this case, before executing the hg qpush -a from above titus@1963: you should manually "hg qdelete" the patches that are already integrated upstream. titus@1963: titus@1963: titus@1963: HOW TO FORMAT COMMIT MESSAGES (aka patch desciptions): yann@1575: yann@1575: Commit messages should look like (without leading pipes): yann@1575: |component: short, one-line description yann@1575: | yann@1575: |optional longer description yann@1575: |on multiple lines if needed yann@1575: yann@1575: Here is an example commit message (see revision a53a5e1d61db): yann@1575: |comp-libs/cloog: fix building yann@1575: | yann@1575: |For CLooG/PPL 0.15.3, the directory name was simply cloog-ppl. yann@1575: |For any later versions, the directory name does have the version, such as yann@1575: |cloog-ppl-0.15.4. yann@1575: yann@1: _____________ yann@1: / yann@1: Internals / yann@1: __________/ yann@1: yann@92: Internally, crosstool-NG is script-based. To ease usage, the frontend is yann@92: Makefile-based. yann@92: yann@92: Makefile front-end | yann@476: -------------------+ yann@92: yann@203: The entry point to crosstool-NG is the Makefile script "ct-ng". Calling this yann@203: script with an action will act exactly as if the Makefile was in the current yann@203: working directory and make was called with the action as rule. Thus: yann@203: ct-ng menuconfig yann@294: yann@203: is equivalent to having the Makefile in CWD, and calling: yann@203: make menuconfig yann@203: yann@203: Having ct-ng as it is avoids copying the Makefile everywhere, and acts as a yann@203: traditional command. yann@203: yann@203: ct-ng loads sub- Makefiles from the library directory $(CT_LIB_DIR), as set up yann@203: at configuration time with ./configure. yann@203: yann@437: ct-ng also searches for config files, sub-tools, samples, scripts and patches in yann@203: that library directory. yann@92: yann@294: Because of a stupid make behavior/bug I was unable to track down, implicit make yann@294: rules are disabled: installing with --local would triger those rules, and mconf yann@294: was unbuildable. yann@294: yann@182: Kconfig parser | yann@476: ---------------+ yann@92: yann@965: The kconfig language is a hacked version, vampirised from the Linux kernel yann@965: (http://www.kernel.org/), and (heavily) adapted to my needs. yann@92: yann@1040: The list of the most notable changes (at least the ones I remember) follows: yann@1040: - the CONFIG_ prefix has been replaced with CT_ yann@1040: - a leading | in prompts is skipped, and subsequent leading spaces are not yann@1843: trimmed; otherwise leading spaces are silently trimmed yann@1843: - removed the warning about undefined environment variable yann@1040: yann@203: The kconfig parsers (conf and mconf) are not installed pre-built, but as yann@203: source files. Thus you can have the directory where crosstool-NG is installed, yann@203: exported (via NFS or whatever) and have clients with different architectures yann@203: use the same crosstool-NG installation, and most notably, the same set of yann@203: patches. yann@203: yann@381: Architecture-specific | yann@476: ----------------------+ yann@381: yann@628: Note: this chapter is not really well written, and might thus be a little bit yann@628: complex to understand. To get a better grasp of what an architecture is, the yann@628: reader is kindly encouraged to look at the "arch/" sub-directory, and to the yann@628: existing architectures to see how things are laid out. yann@628: yann@381: An architecture is defined by: yann@381: yann@381: - a human-readable name, in lower case letters, with numbers as appropriate. yann@628: The underscore is allowed; space and special characters are not. yann@628: Eg.: arm, x86_64 yann@903: - a file in "config/arch/", named after the architecture's name, and suffixed yann@903: with ".in". yann@903: Eg.: config/arch/arm.in yann@903: - a file in "scripts/build/arch/", named after the architecture's name, and yann@903: suffixed with ".sh". yann@903: Eg.: scripts/build/arch/arm.sh yann@628: yann@903: The architecture's ".in" file API: yann@628: > the config option "ARCH_%arch%" (where %arch% is to be replaced with the yann@628: actual architecture name). yann@628: That config option must have *neither* a type, *nor* a prompt! Also, it can yann@628: *not* depend on any other config option (EXPERIMENTAL is managed as above). yann@628: Eg.: yann@628: config ARCH_arm yann@630: + mandatory: yann@702: defines a (terse) help entry for this architecture: yann@630: Eg.: yann@630: config ARCH_arm yann@630: help yann@630: The ARM architecture. yann@628: + optional: yann@628: selects adequate associated config options. yann@1038: Note: 64-bit architectures *shall* select ARCH_64 yann@628: Eg.: yann@628: config ARCH_arm yann@628: select ARCH_SUPPORTS_BOTH_ENDIAN yann@628: select ARCH_DEFAULT_LE yann@630: help yann@630: The ARM architecture. yann@1038: Eg.: yann@1038: config ARCH_x86_64 yann@1038: select ARCH_64 yann@1038: help yann@1038: The x86_64 architecture. yann@628: yann@628: > other target-specific options, at your discretion. Note however that to yann@628: avoid name-clashing, such options shall be prefixed with "ARCH_%arch%", yann@628: where %arch% is again replaced by the actual architecture name. yann@628: (Note: due to historical reasons, and lack of time to clean up the code, yann@628: I may have left some config options that do not completely conform to yann@628: this, as the architecture name was written all upper case. However, the yann@628: prefix is unique among architectures, and does not cause harm). yann@381: yann@903: The architecture's ".sh" file API: yann@965: > the function "CT_DoArchTupleValues" yann@381: + parameters: none yann@381: + environment: yann@901: - all variables from the ".config" file, yann@901: - the two variables "target_endian_eb" and "target_endian_el" which are yann@901: the endianness suffixes yann@381: + return value: 0 upon success, !0 upon failure yann@381: + provides: yann@391: - mandatory yann@383: - the environment variable CT_TARGET_ARCH yann@389: - contains: yann@389: the architecture part of the target tuple. yann@389: Eg.: "armeb" for big endian ARM yann@389: "i386" for an i386 yann@389: + provides: yann@391: - optional yann@389: - the environment variable CT_TARGET_SYS yann@456: - contains: yann@383: the sytem part of the target tuple. yann@383: Eg.: "gnu" for glibc on most architectures yann@383: "gnueabi" for glibc on an ARM EABI yann@383: - defaults to: yann@383: - for glibc-based toolchain: "gnu" yann@383: - for uClibc-based toolchain: "uclibc" yann@383: + provides: yann@383: - optional yann@767: - the environment variables to configure the cross-gcc (defaults) yann@767: - CT_ARCH_WITH_ARCH : the gcc ./configure switch to select architecture level ( "--with-arch=${CT_ARCH_ARCH}" ) yann@767: - CT_ARCH_WITH_ABI : the gcc ./configure switch to select ABI level ( "--with-abi=${CT_ARCH_ABI}" ) yann@767: - CT_ARCH_WITH_CPU : the gcc ./configure switch to select CPU instruction set ( "--with-cpu=${CT_ARCH_CPU}" ) yann@767: - CT_ARCH_WITH_TUNE : the gcc ./configure switch to select scheduling ( "--with-tune=${CT_ARCH_TUNE}" ) yann@767: - CT_ARCH_WITH_FPU : the gcc ./configure switch to select FPU type ( "--with-fpu=${CT_ARCH_FPU}" ) yann@767: - CT_ARCH_WITH_FLOAT : the gcc ./configure switch to select floating point arithmetics ( "--with-float=soft" or /empty/ ) yann@391: + provides: yann@391: - optional yann@767: - the environment variables to pass to the cross-gcc to build target binaries (defaults) yann@391: - CT_ARCH_ARCH_CFLAG : the gcc switch to select architecture level ( "-march=${CT_ARCH_ARCH}" ) yann@456: - CT_ARCH_ABI_CFLAG : the gcc switch to select ABI level ( "-mabi=${CT_ARCH_ABI}" ) yann@391: - CT_ARCH_CPU_CFLAG : the gcc switch to select CPU instruction set ( "-mcpu=${CT_ARCH_CPU}" ) yann@391: - CT_ARCH_TUNE_CFLAG : the gcc switch to select scheduling ( "-mtune=${CT_ARCH_TUNE}" ) yann@391: - CT_ARCH_FPU_CFLAG : the gcc switch to select FPU type ( "-mfpu=${CT_ARCH_FPU}" ) yann@391: - CT_ARCH_FLOAT_CFLAG : the gcc switch to choose floating point arithmetics ( "-msoft-float" or /empty/ ) yann@391: - CT_ARCH_ENDIAN_CFLAG : the gcc switch to choose big or little endian ( "-mbig-endian" or "-mlittle-endian" ) yann@391: - default to: yann@391: see above. yann@767: + provides: yann@767: - optional yann@767: - the environement variables to configure the core and final compiler, specific to this architecture: yann@767: - CT_ARCH_CC_CORE_EXTRA_CONFIG : additional, architecture specific core gcc ./configure flags yann@767: - CT_ARCH_CC_EXTRA_CONFIG : additional, architecture specific final gcc ./configure flags yann@767: - default to: yann@767: - all empty yann@767: + provides: yann@767: - optional yann@767: - the architecture-specific CFLAGS and LDFLAGS: yann@767: - CT_ARCH_TARGET_CLFAGS yann@767: - CT_ARCH_TARGET_LDFLAGS yann@767: - default to: yann@767: - all empty yann@628: yann@903: You can have a look at "config/arch/arm.in" and "scripts/build/arch/arm.sh" for yann@903: a quite complete example of what an actual architecture description looks like. yann@901: yann@890: Kernel specific | yann@890: ----------------+ yann@890: yann@890: A kernel is defined by: yann@890: yann@890: - a human-readable name, in lower case letters, with numbers as appropriate. yann@890: The underscore is allowed; space and special characters are not (although yann@890: they are internally replaced with underscores. yann@890: Eg.: linux, bare-metal yann@890: - a file in "config/kernel/", named after the kernel name, and suffixed with yann@890: ".in". yann@890: Eg.: config/kernel/linux.in, config/kernel/bare-metal.in yann@901: - a file in "scripts/build/kernel/", named after the kernel name, and suffixed yann@901: with ".sh". yann@901: Eg.: scripts/build/kernel/linux.sh, scripts/build/kernel/bare-metal.sh yann@890: yann@890: The kernel's ".in" file must contain: yann@890: > an optional lines containing exactly "# EXPERIMENTAL", starting on the yann@890: first column, and without any following space or other character. yann@890: If this line is present, then this kernel is considered EXPERIMENTAL, yann@890: and correct dependency on EXPERIMENTAL will be set. yann@901: yann@890: > the config option "KERNEL_%kernel_name%" (where %kernel_name% is to be yann@890: replaced with the actual kernel name, with all special characters and yann@890: spaces replaced by underscores). yann@890: That config option must have *neither* a type, *nor* a prompt! Also, it can yann@890: *not* depends on EXPERIMENTAL. yann@890: Eg.: KERNEL_linux, KERNEL_bare_metal yann@890: + mandatory: yann@890: defines a (terse) help entry for this kernel. yann@890: Eg.: yann@890: config KERNEL_bare_metal yann@890: help yann@890: Build a compiler for use without any kernel. yann@890: + optional: yann@890: selects adequate associated config options. yann@890: Eg.: yann@890: config KERNEL_bare_metal yann@890: select BARE_METAL yann@890: help yann@890: Build a compiler for use without any kernel. yann@890: yann@890: > other kernel specific options, at your discretion. Note however that, to yann@890: avoid name-clashing, such options should be prefixed with yann@890: "KERNEL_%kernel_name%", where %kernel_name% is again tp be replaced with yann@890: the actual kernel name. yann@890: (Note: due to historical reasons, and lack of time to clean up the code, yann@890: I may have left some config options that do not completely conform to yann@890: this, as the kernel name was written all upper case. However, the prefix yann@890: is unique among kernels, and does not cause harm). yann@890: yann@901: The kernel's ".sh" file API: yann@901: > is a bash script fragment yann@901: yann@965: > defines the function CT_DoKernelTupleValues yann@965: + see the architecture's CT_DoArchTupleValues, except for: yann@965: + set the environment variable CT_TARGET_KERNEL, the kernel part of the yann@965: target tuple yann@965: + return value: ignored yann@965: yann@901: > defines the function "do_kernel_get": yann@901: + parameters: none yann@901: + environment: yann@901: - all variables from the ".config" file. yann@901: + return value: 0 for success, !0 for failure. yann@901: + behavior: download the kernel's sources, and store the tarball into yann@901: "${CT_TARBALLS_DIR}". To this end, a functions is available, that yann@901: abstracts downloading tarballs: yann@901: - CT_DoGet yann@901: Eg.: CT_DoGet linux-2.6.26.5 ftp://ftp.kernel.org/pub/linux/kernel/v2.6 yann@901: Note: retrieving sources from svn, cvs, git and the likes is not supported yann@901: by CT_DoGet. You'll have to do this by hand, as it is done for eglibc in yann@901: "scripts/build/libc/eglibc.sh" yann@901: yann@901: > defines the function "do_kernel_extract": yann@901: + parameters: none yann@901: + environment: yann@901: - all variables from the ".config" file, yann@901: + return value: 0 for success, !0 for failure. yann@901: + behavior: extract the kernel's tarball into "${CT_SRC_DIR}", and apply yann@901: required patches. To this end, a function is available, that abstracts yann@901: extracting tarballs: yann@901: - CT_ExtractAndPatch yann@901: Eg.: CT_ExtractAndPatch linux-2.6.26.5 yann@901: yann@901: > defines the function "do_kernel_headers": yann@901: + parameters: none yann@901: + environment: yann@901: - all variables from the ".config" file, yann@901: + return value: 0 for success, !0 for failure. yann@901: + behavior: install the kernel headers (if any) in "${CT_SYSROOT_DIR}/usr/include" yann@901: yann@901: > defines any kernel-specific helper functions yann@901: These functions, if any, must be prefixed with "do_kernel_%CT_KERNEL%_", yann@901: where '%CT_KERNEL%' is to be replaced with the actual kernel name, to avoid yann@901: any name-clashing. yann@901: yann@901: You can have a look at "config/kernel/linux.in" and "scripts/build/kernel/linux.sh" yann@903: as an example of what a complex kernel description looks like. yann@901: yann@620: Adding a new version of a component | yann@476: ------------------------------------+ yann@476: yann@476: When a new component, such as the Linux kernel, gcc or any other is released, yann@476: adding the new version to crosstool-NG is quite easy. There is a script that yann@476: will do all that for you: yann@1095: scripts/addToolVersion.sh yann@476: yann@476: Run it with no option to get some help. yann@381: yann@203: Build scripts | yann@476: --------------+ yann@203: yann@203: To Be Written later...