a0871be6c0
* Update buildroot-patches for 2020.11-rc1 buildroot * Update buildroot to 2020.11-rc1 Signed-off-by: Stefan Agner <stefan@agner.ch> * Don't rely on sfdisk --list-free output The --list-free (-F) argument does not allow machine readable mode. And it seems that the output format changes over time (different spacing, using size postfixes instead of raw blocks). Use sfdisk json output and calculate free partition space ourselfs. This works for 2.35 and 2.36 and is more robust since we rely on output which is meant for scripts to parse. * Migrate defconfigs for Buildroot 2020.11-rc1 In particular, rename BR2_TARGET_UBOOT_BOOT_SCRIPT(_SOURCE) to BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT(_SOURCE). * Rebase/remove systemd patches for systemd 246 * Drop apparmor/libapparmor from buildroot-external * hassos-persists: use /run as directory for lockfiles The U-Boot tools use /var/lock by default which is not created any more by systemd by default (it is under tmpfiles legacy.conf, which we no longer install). * Disable systemd-update-done.service The service is not suited for pure read-only systems. In particular the service needs to be able to write a file in /etc and /var. Remove the service. Note: This is a static service and cannot be removed using systemd-preset. * Disable apparmor.service for now The service loads all default profiles. Some might actually cause problems. E.g. the profile for ping seems not to match our setup for /etc/resolv.conf: [85503.634653] audit: type=1400 audit(1605286002.684:236): apparmor="DENIED" operation="open" profile="ping" name="/run/resolv.conf" pid=27585 comm="ping" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
49 lines
2.3 KiB
Plaintext
49 lines
2.3 KiB
Plaintext
// -*- mode:doc; -*-
|
|
// vim: set syntax=asciidoc:
|
|
|
|
==== Using the generated toolchain outside Buildroot
|
|
|
|
You may want to compile, for your target, your own programs or other
|
|
software that are not packaged in Buildroot. In order to do this you
|
|
can use the toolchain that was generated by Buildroot.
|
|
|
|
The toolchain generated by Buildroot is located by default in
|
|
+output/host/+. The simplest way to use it is to add
|
|
+output/host/bin/+ to your PATH environment variable and then to
|
|
use +ARCH-linux-gcc+, +ARCH-linux-objdump+, +ARCH-linux-ld+, etc.
|
|
|
|
Alternatively, Buildroot can also export the toolchain and the development
|
|
files of all selected packages, as an SDK, by running the command
|
|
+make sdk+. This generates a tarball of the content of the host directory
|
|
+output/host/+, named +<TARGET-TUPLE>_sdk-buildroot.tar.gz+ (which can be
|
|
overriden by setting the environment variable +BR2_SDK_PREFIX+) and
|
|
located in the output directory +output/images/+.
|
|
|
|
This tarball can then be distributed to application developers, when
|
|
they want to develop their applications that are not (yet) packaged as
|
|
a Buildroot package.
|
|
|
|
Upon extracting the SDK tarball, the user must run the script
|
|
+relocate-sdk.sh+ (located at the top directory of the SDK), to make
|
|
sure all paths are updated with the new location.
|
|
|
|
Alternatively, if you just want to prepare the SDK without generating
|
|
the tarball (e.g. because you will just be moving the +host+ directory,
|
|
or will be generating the tarball on your own), Buildroot also allows
|
|
you to just prepare the SDK with +make prepare-sdk+ without actually
|
|
generating a tarball.
|
|
|
|
For your convenience, by selecting the option
|
|
+BR2_PACKAGE_HOST_ENVIRONMENT_SETUP+, you can get a
|
|
+setup-environment+ script installed in +output/host/+ and therefore
|
|
in your SDK. This script can be sourced with
|
|
+. your/sdk/path/environment-setup+ to export a number of environment
|
|
variables that will help cross-compile your projects using the
|
|
Buildroot SDK: the +PATH+ will contain the SDK binaries, standard
|
|
_autotools_ variables will be defined with the appropriate values, and
|
|
+CONFIGURE_FLAGS+ will contain basic +./configure+ options to
|
|
cross-compile _autotools_ projects. It also provides some useful
|
|
commands. Note however that once this script is sourced, the
|
|
environment is setup only for cross-compilation, and no longer for
|
|
native compilation.
|