yann@2076: File.........: 3 - Configuring a toolchain.txt yann@2908: Copyright....: (C) 2010 Yann E. MORIN yann@2076: License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5 yann@2076: yann@2076: yann@2076: yann@2076: Configuring crosstool-NG / yann@2076: _________________________/ yann@2076: yann@2076: antony@2564: crosstool-NG is configured with a configurator presenting a menu-structured set yann@2076: of options. These options let you specify the way you want your toolchain yann@2076: built, where you want it installed, what architecture and specific processor it yann@2076: will support, the version of the components you want to use, etc... The yann@2076: value for those options are then stored in a configuration file. yann@2076: yann@2076: The configurator works the same way you configure your Linux kernel. It is yann@2076: assumed you now how to handle this. yann@2076: yann@2076: To enter the menu, type: yann@2076: ct-ng menuconfig yann@2076: yann@2076: Almost every config item has a help entry. Read them carefully. yann@2076: yann@2076: String and number options can refer to environment variables. In such a case, yann@2076: you must use the shell syntax: ${VAR}. You shall neither single- nor double- yann@2076: quote the string/number options. yann@2076: yann@2076: There are three environment variables that are computed by crosstool-NG, and yann@2076: that you can use: yann@2076: yann@2076: CT_TARGET: yann@2076: It represents the target tuple you are building for. You can use it for yann@2076: example in the installation/prefix directory, such as: yann@2076: /opt/x-tools/${CT_TARGET} yann@2076: yann@2076: CT_TOP_DIR: yann@2076: The top directory where crosstool-NG is running. You shouldn't need it in yann@2076: most cases. There is one case where you may need it: if you have local yann@2076: patches and you store them in your running directory, you can refer to them yann@2076: by using CT_TOP_DIR, such as: yann@2076: ${CT_TOP_DIR}/patches.myproject yann@2076: yann@2076: CT_VERSION: yann@2076: The version of crosstool-NG you are using. Not much use for you, but it's yann@2076: there if you need it. yann@2076: yann@2076: yann@2076: Interesting config options | yann@2076: ---------------------------+ yann@2076: yann@2076: CT_LOCAL_TARBALLS_DIR: antony@2564: If you already have some tarballs in a directory, enter it here. That will yann@2076: speed up the retrieving phase, where crosstool-NG would otherwise download yann@2076: those tarballs. yann@2076: yann@2076: CT_PREFIX_DIR: yann@2076: This is where the toolchain will be installed in (and for now, where it yann@2076: will run from). Common use is to add the target tuple in the directory yann@2076: path, such as (see above): yann@2076: /opt/x-tools/${CT_TARGET} yann@2076: yann@2076: CT_TARGET_VENDOR: yann@2076: An identifier for your toolchain, will take place in the vendor part of the yann@2076: target tuple. It shall *not* contain spaces or dashes. Usually, keep it yann@2076: to a one-word string, or use underscores to separate words if you need. yann@2076: Avoid dots, commas, and special characters. yann@2076: yann@2076: CT_TARGET_ALIAS: antony@2564: An alias for the toolchain. It will be used as a prefix to the toolchain yann@2076: tools. For example, you will have ${CT_TARGET_ALIAS}-gcc yann@2076: yann@2076: Also, if you think you don't see enough versions, you can try to enable one of yann@2076: those: yann@2076: yann@2076: CT_OBSOLETE: yann@2076: Show obsolete versions or tools. Most of the time, you don't want to base yann@2076: your toolchain on too old a version (of gcc, for example). But at times, it yann@2076: can come handy to use such an old version for regression tests. Those old yann@2076: versions are hidden behind CT_OBSOLETE. Those versions (or features) are so yann@2076: marked because maintaining support for those in crosstool-NG would be too yann@2076: costly, time-wise, and time is dear. yann@2076: yann@2076: CT_EXPERIMENTAL: yann@2076: Show experimental versions or tools. Again, you might not want to base your yann@2076: toolchain on too recent tools (eg. gcc) for production. But if you need a yann@2076: feature present only in a recent version, or a new tool, you can find them yann@2076: hidden behind CT_EXPERIMENTAL. Those versions (or features) did not (yet) yann@2076: receive thorough testing in crosstool-NG, and/or are not mature enough to yann@2076: be blindly trusted. yann@2076: yann@2076: yann@2076: Re-building an existing toolchain | yann@2076: ----------------------------------+ yann@2076: yann@2076: If you have an existing toolchain, you can re-use the options used to build it yann@2076: to create a new toolchain. That needs a very little bit of effort on your side yann@2076: but is quite easy. The options to build a toolchain are saved with the yann@2076: toolchain, and you can retrieve this configuration by running: yann@2076: ${CT_TARGET}-ct-ng.config yann@2076: yann@2076: An alternate method is to extract the configuration from a build.log file. yann@2076: This will be necessary if your toolchain was build with crosstool-NG prior yann@2076: to 1.4.0, but can be used with build.log files from any version: yann@2076: ct-ng extractconfig .config yann@2076: yann@2076: Or, if your build.log file is compressed (most probably!): yann@2076: bzcat build.log.bz2 |ct-ng extractconfig >.config yann@2076: yann@2076: The above commands will dump the configuration to stdout, so to rebuild a yann@2076: toolchain with this configuration, just redirect the output to the yann@2076: .config file: yann@2076: ${CT_TARGET}-ct-ng.config >.config yann@2076: ct-ng oldconfig yann@2076: yann@2076: Then, you can review and change the configuration by running: yann@2076: ct-ng menuconfig yann@2076: yann@2076: yann@2076: Using as a backend for a build-system | yann@2076: --------------------------------------+ yann@2076: yann@2076: Crosstool-NG can be used as a backend for an automated build-system. In this yann@2076: case, some components that are expected to run on the target (eg. the native yann@2076: gdb, ltrace, DUMA...) are not available in the menuconfig, and they are not yann@2076: build either, as it is considered the responsibility of the build-system to yann@2076: build its own versions of those tools. yann@2076: yann@2076: If you want to use crosstool-NG as a backend to generate your toolchains for yann@2076: your build-system, you have to set and export this environment variable: yann@2076: CT_IS_A_BACKEND=y yann@2076: yann@2076: (case is not sensitive, you can say Y).