diff --git a/docs/buildroot.html b/docs/buildroot.html index 0a0114a3b7..144461298f 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -182,18 +182,23 @@ $ make +

You should never use make -jN with + Buildroot: it does not support top-level parallel + make. Instead, use the BR2_JLEVEL option to tell + Buildroot to run each package compilation with 

make
+    -jN
.

+

This command will generally perform the following steps:

-

Some of the above steps might not be performed if they are not - selected in the Buildroot configuration. -

Buildroot output is stored in a single directory, output/. This directory contains several subdirectories:

@@ -330,19 +335,14 @@ completely rebuild your toolchain and tools, these changes will be lost. -
  • Customize the target filesystem skeleton available under - fs/skeleton/. You can customize configuration files or other - stuff here. However, the full file hierarchy is not yet present - because it's created during the compilation process. Therefore, you - can't do everything on this target filesystem skeleton, but changes to - it do remain even if you completely rebuild the cross-compilation - toolchain and the tools.
    You can also customize the - target/generic/device_table.txt file, which is used by the - tools that generate the target filesystem image to properly set - permissions and create device nodes.
    These customizations are - deployed into output/target/ just before the actual image - is made. Simply rebuilding the image by running make should propagate - any new changes to the image.
    • +
  • Create your own target skeleton. You can start with + the default skeleton available under fs/skeleton + and then customize it to suit your + needs. The BR2_ROOTFS_SKELETON_CUSTOM + and BR2_ROOTFS_SKELETON_CUSTOM_PATH will allow you + to specify the location of your custom skeleton. At build time, + the contents of the skeleton are copied to output/target before + any package installation.
  • Add support for your own target in Buildroot, so that you have your own target skeleton (see this @@ -671,12 +671,9 @@ endif then to use ARCH-linux-gcc, ARCH-linux-objdump, ARCH-linux-ld, etc.

    -

    Important: do not try to move a gcc-3.x toolchain to another - directory — it won't work because there are some hardcoded paths - in the gcc-3.x configuration. If you are using a current gcc-4.x, it is - possible to relocate the toolchain — but then --sysroot - must be passed every time the compiler is called to tell where the - libraries and header files are.

    +

    It is possible to relocate the toolchain — but + then --sysroot must be passed every time the compiler + is called to tell where the libraries and header files are.

    It is also possible to generate the Buildroot toolchain in a directory other than output/staging by using the @@ -713,13 +710,22 @@ endif

    Using an external toolchain

    -

    It might be useful not to use the toolchain generated by - Buildroot, for example if you already have a toolchain that is known - to work for your specific CPU, or if the toolchain generation feature - of Buildroot is not sufficiently flexible for you (for example if you - need to generate a system with glibc instead of - uClibc). Buildroot supports using an external - toolchain.

    +

    Using an already existing toolchain is useful for different + reasons:

    + +
      +
    • you already have a toolchain that is known to work for your + specific CPU
      • +
    • you want to speed up the Buildroot build process by skipping + the long toolchain build part
      • +
    • the toolchain generation feature of Buildroot is not + sufficiently flexible for you (for example if you need to + generate a system with glibc instead of + uClibc)
      • +
    + +

    Buildroot supports using existing toolchains through a + mechanism called external toolchain.

    To enable the use of an external toolchain, go to the Toolchain menu, and :

    @@ -727,6 +733,17 @@ endif
    • Select the External binary toolchain toolchain type
      • +
    • Select the appropriate External toolchain C + library
      • +
    • Select the appropriate values for Enable large + file, Enable IPv6, Enable + RPC, Enable toolchain + locale/i18n, Enable WCHAR, Enable + program invocation, Build/install c++ compiler and + libstdc++, according to the configuration of your + external toolchain. Buildroot will check those values at the + beginning of the compilation process and will tell you if you + used incorrect values.
    • Adjust the External toolchain path appropriately. It should be set to a path where a bin/ directory contains your cross-compiling tools
      • @@ -735,18 +752,12 @@ endif correspond to your cross-compiling tools
    -

    If you are using an external toolchain based on uClibc, the - Core C library from the external toolchain and - Libraries to copy from the external toolchain options - should already have correct values. However, if your external - toolchain is based on glibc, you'll have to change these values - according to your cross-compiling toolchain.

    - -

    To generate external toolchains, we recommend using - Crosstool-NG. - It allows generating toolchains based on uClibc, glibc - and eglibc for a wide range of architectures and has good - community support.

    +

    Our external toolchain support has been tested with toolchains + from CodeSourcery, toolchains generated + by Crosstool-NG, + and toolchains generated by Buildroot itself. In general, all + toolchains that support the sysroot feature should + work. If not, do not hesitate to contact the developers.

    Adding new packages to Buildroot

    @@ -981,9 +992,12 @@ $(eval $(call GENTARGETS,package,libfoo,host)) libfoo) :