From: Romain Naour <romain.naour@openwide.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 02/18] gcc: use toolchain wrapper
Date: Sat, 3 Oct 2015 21:42:33 +0200 [thread overview]
Message-ID: <56102FA9.3030109@openwide.fr> (raw)
In-Reply-To: <1442774504-22799-3-git-send-email-arnout@mind.be>
Hi Arnout,
Le 20/09/2015 20:41, Arnout Vandecappelle (Essensium/Mind) a ?crit :
> We have a toolchain wrapper for external toolchain, but it is also
> beneficial for internal toolchains, for the following reasons:
>
> 1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the
> compiler even if a package's build system doesn't honor CFLAGS.
> 2. It allows us to do the unsafe path check (i.e. -I/usr/include)
> without patching gcc.
> 3. It makes it simpler to implement building each package with a
> separate staging directory (per-package staging).
> 4. It makes it simpler to implement a compiler hash check for ccache.
>
> The wrapper is reused from the external toolchain. A third CROSS_PATH_
> option is added to the wrapper: in this case, the real executable is in
> the same directory, with the extension .real.
>
> The creation of the simple symlinks is merged with the creation of the
> wrapper symlinks, otherwise part of the -gcc-ar handling logic would
> have to be repeated.
>
> The complex case-condition could be refactored with the one for the
> external toolchain, but then it becomes even more complex because
> they each have special corner cases. For example, the internal
> toolchain has to handle *.real to avoid creating an extra indirection
> after host-gcc-{final,initial}-rebuild.
>
> Instead of creating the .real files, it would also have been possible
> to install the internal toolchain in $(HOST_DIR)/opt, similar to what
> we do for the external toolchain. However, then we would also have to
> copy things to the sysroot and do more of the magic that the external
> toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much
> simpler.
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
> Cc: J?r?me Oufella <jerome.oufella@savoirfairelinux.com>
> ---
> package/gcc/gcc-final/gcc-final.mk | 13 +++++--------
> package/gcc/gcc-initial/gcc-initial.mk | 4 ++++
> package/gcc/gcc.mk | 35 ++++++++++++++++++++++++++++++++++
> toolchain/toolchain-wrapper.c | 4 +++-
> 4 files changed, 47 insertions(+), 9 deletions(-)
>
> diff --git a/package/gcc/gcc-final/gcc-final.mk b/package/gcc/gcc-final/gcc-final.mk
> index 3426ba4..2c16fdf 100644
> --- a/package/gcc/gcc-final/gcc-final.mk
> +++ b/package/gcc/gcc-final/gcc-final.mk
> @@ -96,14 +96,11 @@ endef
>
> HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_FINAL_CREATE_CC_SYMLINKS
>
> -# Create <arch>-linux-<tool> symlinks
> -define HOST_GCC_FINAL_CREATE_SIMPLE_SYMLINKS
> - (cd $(HOST_DIR)/usr/bin; for i in $(GNU_TARGET_NAME)-*; do \
> - ln -snf $$i $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
> - done)
> -endef
> -
> -HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_FINAL_CREATE_SIMPLE_SYMLINKS
> +HOST_GCC_FINAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS)
> +HOST_GCC_FINAL_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER
> +# Note: this must be done after CREATE_CC_SYMLINKS, otherwise the
> +# -cc symlink to the wrapper is not created.
> +HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
>
> # In gcc 4.7.x, the ARM EABIhf library loader path for (e)glibc was not
> # correct, so we create a symbolic link to make things work
> diff --git a/package/gcc/gcc-initial/gcc-initial.mk b/package/gcc/gcc-initial/gcc-initial.mk
> index 6bb7997..4b03e47 100644
> --- a/package/gcc/gcc-initial/gcc-initial.mk
> +++ b/package/gcc/gcc-initial/gcc-initial.mk
> @@ -62,4 +62,8 @@ HOST_GCC_INITIAL_MAKE_OPTS += all-target-libgcc
> HOST_GCC_INITIAL_INSTALL_OPTS += install-target-libgcc
> endif
>
> +HOST_GCC_INITIAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS)
> +HOST_GCC_INITIAL_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER
> +HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
> +
I was wondering why we had to use the wrapper for the gcc-initial until I figure
out that it's used when the libc is build.
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Best regards,
Romain
> $(eval $(host-autotools-package))
> diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
> index 501fcea..9044040 100644
> --- a/package/gcc/gcc.mk
> +++ b/package/gcc/gcc.mk
> @@ -235,4 +235,39 @@ HOST_GCC_COMMON_CONF_OPTS += \
> --with-long-double-128
> endif
>
> +HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".real"'
> +
> +# The LTO support in gcc creates wrappers for ar, ranlib and nm which load
> +# the lto plugin. These wrappers are called *-gcc-ar, *-gcc-ranlib, and
> +# *-gcc-nm and should be used instead of the real programs when -flto is
> +# used. However, we should not add the toolchain wrapper for them, and they
> +# match the *cc-* pattern. Therefore, an additional case is added for *-ar,
> +# *-ranlib and *-nm.
> +# Avoid that a .real is symlinked a second time.
> +# Also create <arch>-linux-<tool> symlinks.
> +define HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS
> + $(Q)cd $(HOST_DIR)/usr/bin; \
> + for i in $(GNU_TARGET_NAME)-*; do \
> + case "$$i" in \
> + *.real) \
> + ;; \
> + *-ar|*-ranlib|*-nm) \
> + ln -snf $$i $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
> + ;; \
> + *cc|*cc-*|*++|*++-*|*cpp) \
> + rm -f $$i.real; \
> + mv $$i $$i.real; \
> + ln -sf toolchain-wrapper $$i; \
> + ln -sf toolchain-wrapper $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
> + ln -snf $$i.real $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}.real; \
> + ;; \
> + *) \
> + ln -snf $$i $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
> + ;; \
> + esac; \
> + done
> +
> +endef
> +
> +
> include $(sort $(wildcard package/gcc/*/*.mk))
> diff --git a/toolchain/toolchain-wrapper.c b/toolchain/toolchain-wrapper.c
> index b3b02d8..f3ff04f 100644
> --- a/toolchain/toolchain-wrapper.c
> +++ b/toolchain/toolchain-wrapper.c
> @@ -138,8 +138,10 @@ int main(int argc, char **argv)
> /* Fill in the relative paths */
> #ifdef BR_CROSS_PATH_REL
> ret = snprintf(path, sizeof(path), "%s/" BR_CROSS_PATH_REL "/%s", absbasedir, basename);
> -#else /* BR_CROSS_PATH_ABS */
> +#elif BR_CROSS_PATH_ABS
> ret = snprintf(path, sizeof(path), BR_CROSS_PATH_ABS "/%s", basename);
> +#else /* BR_CROSS_PATH_SUFFIX */
> + ret = snprintf(path, sizeof(path), "%s/usr/bin/%s" BR_CROSS_PATH_SUFFIX, absbasedir, basename);
> #endif
> if (ret >= sizeof(path)) {
> perror(__FILE__ ": overflow");
>
next prev parent reply other threads:[~2015-10-03 19:42 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-20 18:41 [Buildroot] Internal toolchain wrapper & ccache fixes Arnout Vandecappelle
2015-09-20 18:41 ` [Buildroot] [PATCH 01/18] toolchain-external: move wrapper to toolchain directory Arnout Vandecappelle
2015-10-03 18:45 ` Romain Naour
2015-09-20 18:41 ` [Buildroot] [PATCH 02/18] gcc: use toolchain wrapper Arnout Vandecappelle
2015-10-03 19:42 ` Romain Naour [this message]
2015-09-20 18:41 ` [Buildroot] [PATCH 03/18] gcc: remove unsafe patch check (poison system dirs) patch Arnout Vandecappelle
2015-10-03 19:47 ` Romain Naour
2015-09-20 18:41 ` [Buildroot] [PATCH 04/18] infra: move ccache handling to the toolchain wrapper Arnout Vandecappelle
2015-10-03 21:02 ` Romain Naour
2015-09-20 18:41 ` [Buildroot] [PATCH 05/18] perl: Remove ccache handling Arnout Vandecappelle
2015-10-03 21:07 ` Romain Naour
2015-09-20 18:41 ` [Buildroot] [PATCH 06/18] imx-lib: remove now-redundant " Arnout Vandecappelle
2015-10-03 21:11 ` Romain Naour
2015-10-03 21:16 ` Romain Naour
2015-09-20 18:41 ` [Buildroot] [PATCH 07/18] imx-vpu: " Arnout Vandecappelle
2015-10-03 21:22 ` Romain Naour
2015-09-20 18:41 ` [Buildroot] [PATCH 08/18] linux: " Arnout Vandecappelle
2015-10-03 21:23 ` Romain Naour
2015-09-20 19:23 ` [Buildroot] [PATCH 09/18] uboot: " Arnout Vandecappelle
2015-09-20 19:23 ` [Buildroot] [PATCH 10/18] barebox: " Arnout Vandecappelle
2015-10-03 21:25 ` Romain Naour
2015-09-20 19:23 ` [Buildroot] [PATCH 11/18] cryptodev-linux: remove now-redundant fix-ccache-compile patch Arnout Vandecappelle
2015-10-03 21:34 ` Romain Naour
2015-09-20 19:23 ` [Buildroot] [PATCH 12/18] qt5base: remove now-redundant ccache handling Arnout Vandecappelle
2015-10-03 21:43 ` Romain Naour
2015-09-20 19:23 ` [Buildroot] [PATCH 13/18] package-cmake: remove now-redundant target ccache support Arnout Vandecappelle
2015-10-04 9:32 ` Romain Naour
2015-10-03 21:24 ` [Buildroot] [PATCH 09/18] uboot: remove now-redundant ccache handling Romain Naour
2015-09-20 19:28 ` [Buildroot] [PATCH 14/19] package-cmake: remove now-redundant target ccache support Arnout Vandecappelle
2015-09-20 19:28 ` [Buildroot] [PATCH 15/19] qpid-proton: remove now-redundant ccache handling patch Arnout Vandecappelle
2015-10-04 9:44 ` Romain Naour
2015-09-20 19:28 ` [Buildroot] [PATCH 16/19] Makefile.in: remove now-unused TARGET_CC/CXX_NOCCACHE Arnout Vandecappelle
2015-10-04 9:48 ` Romain Naour
2015-09-20 19:28 ` [Buildroot] [PATCH 17/19] [RFC] toolchain-wrapper: support change of BR2_CCACHE Arnout Vandecappelle
2015-10-04 10:13 ` Romain Naour
2015-09-20 19:28 ` [Buildroot] [PATCH 18/19] ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain Arnout Vandecappelle
2015-09-21 21:43 ` Samuel Martin
2015-09-21 22:32 ` Arnout Vandecappelle
2015-09-22 19:25 ` Samuel Martin
2015-09-20 19:28 ` [Buildroot] [PATCH 19/19] [RFC] ccache: support changing the output directory Arnout Vandecappelle
2015-09-20 19:32 ` [Buildroot] [PATCH 14/19] package-cmake: remove now-redundant target ccache support Arnout Vandecappelle
2015-10-03 21:49 ` Romain Naour
2015-09-21 21:43 ` [Buildroot] Internal toolchain wrapper & ccache fixes Samuel Martin
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=56102FA9.3030109@openwide.fr \
--to=romain.naour@openwide.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.