From 0d2804011b3ac9f1b204bec654a6effeb9e990e1 Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni 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, You should never use
- output/
.
This directory contains several subdirectories: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:
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 If you are using an external toolchain based on uClibc, the
- 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 output/staging
by using the
--
cgit v1.2.3
From 6e2a35c9d484bdea1d7494c2569336a3a3af3816 Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni
- External binary toolchain
toolchain
typeExternal toolchain C
+ library
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.External toolchain path
appropriately. It should be set to a path where a bin/ directory
contains your cross-compiling toolsCore 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.
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:
+ +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 :
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.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
.
- LIBFOO_SITE=http://www.libfoosoftware.org/libfoo
.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
- 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.
- 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.output/target/
just before the actual image
- is made. Simply rebuilding the image by running make should propagate
- any new changes to the image.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.