From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] core/sdk: generate the SDK tarball ourselves
Date: Sat, 9 Jun 2018 23:16:09 +0200 [thread overview]
Message-ID: <20180609211609.GA419@scaer> (raw)
In-Reply-To: <20180609210607.13259-1-yann.morin.1998@free.fr>
All,
On 2018-06-09 23:06 +0200, Yann E. MORIN spake thusly:
> 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 [0], which is very bad practice, because when
I forgot to add the reference to the tarbomb:
https://en.wikipedia.org/wiki/Tar_(computing)#Tarbomb
Regards,
Yann E. MORIN.
> 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
> with.
>
> 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@free.fr>
> Cc: Wolfgang Grandegger <wg@grandegger.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> Cc: Stefan Becker <chemobejk@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
> --- a/Makefile
> +++ b/Makefile
> @@ -574,13 +574,18 @@ prepare: $(BUILD_DIR)/buildroot-config/auto.conf
> world: target-post-image
>
> .PHONY: sdk
> -sdk: world
> +sdk: world $(BR2_TAR_HOST_DEPENDENCY)
> @$(call MESSAGE,"Rendering the SDK relocatable")
> $(TOPDIR)/support/scripts/fix-rpath host
> $(TOPDIR)/support/scripts/fix-rpath staging
> $(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
> $(STAGING_DIR):
> diff --git a/docs/manual/using-buildroot-toolchain.txt b/docs/manual/using-buildroot-toolchain.txt
> index 3246dc2411..d1490b4c38 100644
> --- a/docs/manual/using-buildroot-toolchain.txt
> +++ b/docs/manual/using-buildroot-toolchain.txt
> @@ -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
> +location.
>
> +.Note
> +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.
> --
> 2.14.1
>
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2018-06-09 21:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-09 21:06 [Buildroot] [PATCH] core/sdk: generate the SDK tarball ourselves Yann E. MORIN
2018-06-09 21:16 ` Yann E. MORIN [this message]
2018-06-10 6:03 ` Thomas Petazzoni
2018-06-10 7:47 ` Yann E. MORIN
2018-06-10 21:21 ` Arnout Vandecappelle
2018-06-11 17:20 ` Trent Piepho
2018-06-11 19:01 ` Thomas Petazzoni
2018-06-11 22:10 ` Trent Piepho
2018-06-12 9:57 ` Thomas Petazzoni
2018-06-12 17:11 ` Trent Piepho
2018-06-12 13:30 ` Arnout Vandecappelle
2018-06-12 17:47 ` Trent Piepho
2018-06-12 18:07 ` Stefan Becker
2018-06-12 19:01 ` Thomas Petazzoni
2018-06-12 19:25 ` Stefan Becker
2018-06-13 8:32 ` Andreas Naumann
2018-06-13 10:12 ` Arnout Vandecappelle
2018-06-13 15:46 ` Andreas Naumann
2018-06-13 9:47 ` Arnout Vandecappelle
2018-06-13 9:57 ` Thomas Petazzoni
2018-06-13 10:03 ` Stefan Becker
2018-06-13 11:58 ` Thomas Petazzoni
2018-06-15 18:27 ` Peter Korsgaard
2018-06-13 7:46 ` Arnout Vandecappelle
2018-06-13 7:59 ` Stefan Becker
2018-06-15 18:12 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180609211609.GA419@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.