[Buildroot] [PATCH] core/sdk: generate the SDK tarball ourselves
Yann E. MORIN
yann.morin.1998 at free.fr
Sat Jun 9 21:06:07 UTC 2018
Currently, the wording in the manual instructs the user to generate
tarball from "the contents of the +output/host+ directory".
This is pretty confusing, because taken literally, this would amount to
runing a command like:
tar cf my-sdk.tar -C output/host/ .
This creates a tarbomb , which is very bad practice, because when
extracted, it creates mutiple files in the current directory.
One one really want to do, is create a tarball of the host/ directory,
with something like:
tar cf my-sdk.tar -C output host/
However, this is not much better, because the top-most dirdctory would
have a very common name, host/, which is pretty easy to get conflict
So, we fix that mess by creating the archive ourselves, giving it and
the top-most directory a recogniseable name, based on the target tuple
and the Buildroot version.
Since this is an output file, we located it in the images/ directory.
Update the manual accordignly.
Speaking of the manual.. It was referring to "output/host/", but that
is only valid for in-tree builds. For out-of-tree builds, this is just
"host/". To avoid confusion, use the name of the vairiable $(HOST_DIR),
which, fortunately, happens to be valid in both cases.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
Cc: Wolfgang Grandegger <wg at grandegger.com>
Cc: Thomas Petazzoni <thomas.petazzoni at bootlin.com>
Cc: Arnout Vandecappelle <arnout at mind.be>
Cc: Stefan Becker <chemobejk at gmail.com>
Makefile | 7 ++++++-
docs/manual/using-buildroot-toolchain.txt | 26 +++++++++++++++++---------
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index 4b998bdb65..3f460f8d92 100644
@@ -574,13 +574,18 @@ prepare: $(BUILD_DIR)/buildroot-config/auto.conf
+sdk: world $(BR2_TAR_HOST_DEPENDENCY)
@$(call MESSAGE,"Rendering the SDK relocatable")
$(INSTALL) -m 755 $(TOPDIR)/support/misc/relocate-sdk.sh $(HOST_DIR)/relocate-sdk.sh
mkdir -p $(HOST_DIR)/share/buildroot
echo $(HOST_DIR) > $(HOST_DIR)/share/buildroot/sdk-location
+ $(Q)mkdir -p $(BINARIES_DIR)
+ $(TAR) czf $(BINARIES_DIR)/buildroot-sdk.$(GNU_TARGET_NAME)-$(BR2_VERSION_FULL).tar.gz \
+ -C $(HOST_DIR) \
+ --transform='s#^\.#buildroot-sdk.$(GNU_TARGET_NAME)-$(BR2_VERSION_FULL)#' \
# Populating the staging with the base directories is handled by the skeleton package
diff --git a/docs/manual/using-buildroot-toolchain.txt b/docs/manual/using-buildroot-toolchain.txt
index 3246dc2411..d1490b4c38 100644
@@ -12,15 +12,23 @@ The toolchain generated by Buildroot is located by default in
+output/host/bin/+ to your PATH environment variable and then to
use +ARCH-linux-gcc+, +ARCH-linux-objdump+, +ARCH-linux-ld+, etc.
-It is possible to relocate the toolchain, this allows to distribute
-the toolchain to other developers to build applications for your
-target. To achieve this:
+Alternatively, Buildroot can also export the toolchain and all 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 +$(HOST_DIR)+, named +buildroot-sdk.<TARGET-TUPLE>-<BR-VERSION>.tar.gz+
+and located in the output directory +$(BINARIES_DIR)+.
-* run +make sdk+, which prepares the toolchain to be relocatable;
-* tarball the contents of the +output/host+ directory;
-* distribute the resulting tarball.
+This tarball can then be distributed to application developpers, when
+they want to develop their applications that are not (yet) packaged as
+a Buildroot package.
-Once the toolchain is installed to the new location, the user must run
-the +relocate-sdk.sh+ script to make sure all paths are updated with
-the new location.
+Upon extracting the SDK tarball, the user must run the script
++relocate-sdk.sh+, to make sure all paths are updated with the new
+This SDK can not be re-used as an external toolchain, because it
+contains pre-built libraries that could be conflicting with the ones
+packaged in Buildroot (e.g. when an old SDK would be re-used with a
+newer Buildroot version), unless it was built from a configuration
+with no package enabled.
More information about the buildroot