From 0d2804011b3ac9f1b204bec654a6effeb9e990e1 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 24 Nov 2010 11:56:27 +0100 Subject: documentation: clarify Buildroot steps Signed-off-by: Thomas Petazzoni --- docs/buildroot.html | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/buildroot.html b/docs/buildroot.html index 0a0114a3b..0b87bffed 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -185,15 +185,14 @@

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:

-- cgit v1.2.3 From f6ec679f7b290489e177457ae40bce28371a8d88 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 24 Nov 2010 11:57:34 +0100 Subject: documentation: Tell not to use make -jN Signed-off-by: Thomas Petazzoni --- docs/buildroot.html | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/buildroot.html b/docs/buildroot.html index 0b87bffed..571414b8f 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -182,6 +182,12 @@ $ 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:

  • Download source files (as required)
    • -- cgit v1.2.3 From 167302e722ed84dff2f673d88682444e4d0ef6ac Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 24 Nov 2010 11:59:02 +0100 Subject: documentation: Remove mention of gcc 3.x We don't support gcc 3.x anymore, so get rid of 3.x-specific details Signed-off-by: Thomas Petazzoni --- docs/buildroot.html | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/docs/buildroot.html b/docs/buildroot.html index 571414b8f..333ea224d 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -676,12 +676,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 -- cgit v1.2.3 From 6e2a35c9d484bdea1d7494c2569336a3a3af3816 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 24 Nov 2010 12:02:20 +0100 Subject: documentation: Update details about external toolchains Signed-off-by: Thomas Petazzoni --- docs/buildroot.html | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/docs/buildroot.html b/docs/buildroot.html index 333ea224d..aed385694 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -729,6 +729,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
      • @@ -737,13 +748,6 @@ 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 -- cgit v1.2.3 From 5cf1ce9b62f11715fcee1883aef19ccb685cab5a Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 24 Nov 2010 12:04:03 +0100 Subject: documentation: Mention which external toolchains we tested Signed-off-by: Thomas Petazzoni --- docs/buildroot.html | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/buildroot.html b/docs/buildroot.html index aed385694..9ea037417 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -748,11 +748,12 @@ endif correspond to your cross-compiling tools

-

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

-- cgit v1.2.3 From a88ba3eee0be79a45829b9d98b3c9bf3a93bcea4 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 24 Nov 2010 12:05:52 +0100 Subject: documentation: Reword introduction about external toolchains Signed-off-by: Thomas Petazzoni --- docs/buildroot.html | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/docs/buildroot.html b/docs/buildroot.html index 9ea037417..0115f00f4 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -715,13 +715,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 :

-- cgit v1.2.3 From 3aac10520a4b175b99c38ce375bbab78275c135d Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 24 Nov 2010 12:14:41 +0100 Subject: documentation: Document the GIT/SVN download capabilities Signed-off-by: Thomas Petazzoni --- docs/buildroot.html | 46 +++++++++++++++++++++++++++++++++++++--------- 1 file changed, 37 insertions(+), 9 deletions(-) diff --git a/docs/buildroot.html b/docs/buildroot.html index 0115f00f4..44aadf43e 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -997,9 +997,12 @@ $(eval $(call GENTARGETS,package,libfoo,host)) libfoo) :

    -
  • LIBFOO_VERSION, mandatory, must contain the version - of the package. Note that if HOST_LIBFOO_VERSION doesn't - exist, it is assumed to be the same as LIBFOO_VERSION.
    +
  • LIBFOO_VERSION, mandatory, must contain the + version of the package. Note that + if HOST_LIBFOO_VERSION doesn't exist, it is assumed + to be the same as LIBFOO_VERSION. It can also be a + Subversion or Git branch or tag, for packages that are fetched + directly from their revision control system.
    Example: LIBFOO_VERSION = 0.1.2
  • LIBFOO_SOURCE may contain the name of the tarball of @@ -1018,13 +1021,38 @@ $(eval $(call GENTARGETS,package,libfoo,host)) in the package directory inside Buildroot will be applied to the package after extraction.
    • -
  • LIBFOO_SITE may contain the Internet location of the - tarball of the package. If HOST_LIBFOO_SITE is not - specified, it defaults to LIBFOO_SITE. If none are - specified, then the location is assumed to be +
  • LIBFOO_SITE may contain the Internet location + of the package. It can either be the HTTP or FTP location of a + tarball, or the URL of a Git or Subversion repository + (see LIBFOO_SITE_METHOD + below). If HOST_LIBFOO_SITE is not specified, it + defaults to LIBFOO_SITE. If none are specified, + then the location is assumed to be http://$$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/packagename. -
    Example: - LIBFOO_SITE=http://www.libfoosoftware.org/libfoo.
    • +
    Examples:
    + LIBFOO_SITE=http://www.libfoosoftware.org/libfoo
    + LIBFOO_SITE=http://svn.xiph.org/trunk/Tremor/ + +
  • LIBFOO_SITE_METHOD may contain the method to + fetch the package source code. It can either + be WGET (for normal FTP/HTTP downloads of + tarballs), SVN or GIT. When not + specified, it is guessed from the URL given + in LIBFOO_SITE: git:// + and svn:// URLs will use the GIT + and SVN methods respectively. All other URL-types + will use the WGET method. So for example, in the + case of a package whose source code is available through + Subversion repository on HTTP, one must + specifiy LIBFOO_SITE_METHOD=SVN. For SVN + and GIT methods, what Buildroot does is a + checkout/clone of the repository which is then tarballed and + stored into the download cache. Next builds will not + checkout/clone again, but will use the tarball + directly. When HOST_LIBFOO_SITE_METHOD is not + specified, it defaults to the value + of LIBFOO_SITE_METHOD. See package/multimedia/tremor/ + for an example.
  • LIBFOO_DEPENDENCIES lists the dependencies (in terms of package name) that are required for the current target package to -- cgit v1.2.3 From 49b3ac65607d855889671b27cd6b9f6c1e4f6417 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 24 Nov 2010 13:20:09 +0100 Subject: documentation: Mention the fact that the skeleton location can be configured Signed-off-by: Thomas Petazzoni --- docs/buildroot.html | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/docs/buildroot.html b/docs/buildroot.html index 44aadf43e..144461298 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -335,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 -- cgit v1.2.3