[Buildroot] Issues with the toolchain wrapper applied to the internal toolchain

[Buildroot] Issues with the toolchain wrapper applied to the internal toolchain

[Thomas Petazzoni]

Hello,

Since the toolchain wrapper support for the internal toolchain has been
merged, using pre-built Buildroot toolchains as external toolchains no
longer work since the path logic in the wrapper doesn't cope with a
toolchain installed in host/opt/ext-toolchain/. When executing the
cross-compiler:

thomas at skate:~/projets/buildroot3 (master)$ ./output/host/opt/ext-toolchain/bin/arm-linux-gcc 
/home/thomas/projets/buildroot3/output/host/opt/usr/bin/arm-linux-gcc.real: No such file or directory

As you can see, it looks for the "real" compiler in the wrong location.
I believe it should instead re-use some of the logic of
BR_CROSS_PATH_REL.

You can reproduce this issue by using the following defconfig:

BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2015.08-532-ga237b40.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_4_7=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_10=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y

Also, another concern I have is what going to happen with the double
wrapper? A Buildroot toolchain has a wrapper, and then when it's
re-used as an external toolchain, another wrapper is created. Will this
work OK, especially in terms of ccache behavior?

Thanks, 

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Issues with the toolchain wrapper applied to the internal toolchain

[Arnout Vandecappelle]

On 11-10-15 12:08, Thomas Petazzoni wrote:
> Hello,
> 
> Since the toolchain wrapper support for the internal toolchain has been
> merged, using pre-built Buildroot toolchains as external toolchains no
> longer work since the path logic in the wrapper doesn't cope with a
> toolchain installed in host/opt/ext-toolchain/. 


 Hm, I tested the existing buildroot toolchains, but I didn't think of testing
the new internal toolchain as an external toolchain...


> When executing the
> cross-compiler:
> 
> thomas at skate:~/projets/buildroot3 (master)$ ./output/host/opt/ext-toolchain/bin/arm-linux-gcc 
> /home/thomas/projets/buildroot3/output/host/opt/usr/bin/arm-linux-gcc.real: No such file or directory
> 
> As you can see, it looks for the "real" compiler in the wrong location.
> I believe it should instead re-use some of the logic of
> BR_CROSS_PATH_REL.

 Actually I don't see how this could happen, but I'm too tired now to study it
in detail.

> 
> You can reproduce this issue by using the following defconfig:
> 
> BR2_arm=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
> BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
> BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2015.08-532-ga237b40.tar.bz2"
> BR2_TOOLCHAIN_EXTERNAL_GCC_4_7=y
> BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_10=y
> BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
> # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
> BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
> BR2_TOOLCHAIN_EXTERNAL_CXX=y
> 
> Also, another concern I have is what going to happen with the double
> wrapper? A Buildroot toolchain has a wrapper, and then when it's
> re-used as an external toolchain, another wrapper is created. Will this
> work OK, especially in terms of ccache behavior?

 Good point. Also if we add something like that galileo-specific option to the
toolchain wrapper, we probably don't want it (or repeat it) when used as an
external toolchain.

 One solution for both issues would be to deal with buildroot-built toolchains
explicitly in the toolchain wrapper, i.e. detect the existence of .real and exec
that one directly. Would that be an acceptable solution?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Issues with the toolchain wrapper applied to the internal toolchain

[Arnout Vandecappelle]

On 11-10-15 22:07, Arnout Vandecappelle wrote:
> On 11-10-15 12:08, Thomas Petazzoni wrote:
[snip]
>> As you can see, it looks for the "real" compiler in the wrong location.
>> I believe it should instead re-use some of the logic of
>> BR_CROSS_PATH_REL.
> 
>  Actually I don't see how this could happen, but I'm too tired now to study it
> in detail.

 The problem is that the absolute path is constructed based on $(HOST_DIR)
relative to the location of the executable. That means that the /usr bit is
included. However, in the external toolchain tarballs, the /usr bit is left out.

 I think it's time that we remove the usr part of HOST_DIR. It's quite useless
IMHO. However, it's a pretty big change...

 Specifically for the internal toolchain wrapper, we could calculate abspath
differently for the internal and the external case. Not really ideal if you ask me.


[snip]
>> Also, another concern I have is what going to happen with the double
>> wrapper? A Buildroot toolchain has a wrapper, and then when it's
>> re-used as an external toolchain, another wrapper is created. Will this
>> work OK, especially in terms of ccache behavior?
> 
>  Good point. Also if we add something like that galileo-specific option to the
> toolchain wrapper, we probably don't want it (or repeat it) when used as an
> external toolchain.
> 
>  One solution for both issues would be to deal with buildroot-built toolchains
> explicitly in the toolchain wrapper, i.e. detect the existence of .real and exec
> that one directly. Would that be an acceptable solution?

 Since this solution will be a lot easier, and we probably want it anyway for
the ccache and arch-options issue, I will go for this solution.

 The question is then: do we detect the existence of .real at runtime in the
wrapper itself, or when building the toolchain wrapper?

 I'll try to find time this evening to work this out.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Issues with the toolchain wrapper applied to the internal toolchain

[Thomas Petazzoni]

Arnout,

On Sun, 11 Oct 2015 22:07:52 +0200, Arnout Vandecappelle wrote:

>  One solution for both issues would be to deal with buildroot-built toolchains
> explicitly in the toolchain wrapper, i.e. detect the existence of .real and exec
> that one directly. Would that be an acceptable solution?

I think there are other situations where a .real file could exist, for
example for FLAT toolchains, there is often a wrapper that will call
elf2flt, and the real compiler is also called <something>.real, if I
remember correctly.

So maybe we need to adjust this to .buildroot-real or something that is
less likely to cause any sort of mis-detection?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Issues with the toolchain wrapper applied to the internal toolchain

[Arnout Vandecappelle]

On 14-10-15 10:58, Thomas Petazzoni wrote:
> Arnout,
> 
> On Sun, 11 Oct 2015 22:07:52 +0200, Arnout Vandecappelle wrote:
> 
>>  One solution for both issues would be to deal with buildroot-built toolchains
>> explicitly in the toolchain wrapper, i.e. detect the existence of .real and exec
>> that one directly. Would that be an acceptable solution?
> 
> I think there are other situations where a .real file could exist, for
> example for FLAT toolchains, there is often a wrapper that will call
> elf2flt, and the real compiler is also called <something>.real, if I
> remember correctly.

 If that is the case, it will be an issue for the internal toolchain wrapper as
well, since it will just overwrite the .real...

 But of course, we don't have an internal toolchain for Blackfin anymore, so
I'll try to create an ARM FLAT toolchain and see how far I get...

> 
> So maybe we need to adjust this to .buildroot-real or something that is
> less likely to cause any sort of mis-detection?

 Doesn't look great but it would work.

 Another option is to move it to a subdirectory:
$(HOST_DIR)/usr/bin/toolchain-binaries or something like that.

 Regards,
 Arnout

> 
> Thomas
> 

-- 
Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Issues with the toolchain wrapper applied to the internal toolchain

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

>> One solution for both issues would be to deal with buildroot-built toolchains
 >> explicitly in the toolchain wrapper, i.e. detect the existence of .real and exec
 >> that one directly. Would that be an acceptable solution?

 >  Since this solution will be a lot easier, and we probably want it anyway for
 > the ccache and arch-options issue, I will go for this solution.

 >  The question is then: do we detect the existence of .real at runtime in the
 > wrapper itself, or when building the toolchain wrapper?

I would personally prefer to keep the wrapper as simple as possible (and
errors to show up at build time and not runtime), so I would prefer to
do it when building the wrapper.

 >  I'll try to find time this evening to work this out.

Great, thanks!

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 1/2] gcc: use '.br_real' instead of '.real' for the wrapped toolchain

[Arnout Vandecappelle]

If an externally built toolchain also wraps the toolchain executables,
there is a risk that it will also use the '.real' extension. To
minimise this risk, use a more buildroot-specific extension instead:
'.br_real'.

For the time being, this is not yet a problem since the internal
toolchain never has such a wrapper. However, in a later commit we
will bypass the buildroot wrapper for external toolchains, so we
have to avoid doing that when it's not buildroot that wrapped it.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
Note: I didn't check if any of our external toolchains actually has
such a .real thingy, but better safe than sorry.
---
 package/gcc/gcc.mk | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index 1b30e6d..ef606c4 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -236,7 +236,7 @@ HOST_GCC_COMMON_CONF_OPTS += \
 	--with-long-double-128
 endif
 
-HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".real"'
+HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".br_real"'
 
 ifeq ($(BR2_CCACHE),y)
 HOST_GCC_COMMON_CCACHE_HASH_FILES += $(DL_DIR)/$(GCC_SOURCE)
@@ -272,23 +272,23 @@ endif # BR2_CCACHE
 # 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.
+# Avoid that a .br_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) \
+		*.br_real) \
 			;; \
 		*-ar|*-ranlib|*-nm) \
 			ln -snf $$i $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
 			;; \
 		*cc|*cc-*|*++|*++-*|*cpp) \
-			rm -f $$i.real; \
-			mv $$i $$i.real; \
+			rm -f $$i.br_real; \
+			mv $$i $$i.br_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.br_real $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}.br_real; \
 			;; \
 		*) \
 			ln -snf $$i $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \
-- 
2.5.3

[Buildroot] [PATCH 2/2] toolchain-external: bypass buildroot wrapper

[Arnout Vandecappelle]

The buildroot internal toolchain now adds a wrapper. When we use a
buildroot toolchain as an external toolchain, we want to bypass this
wrapper and call the compiler directly, for two reasons:

1. The options added by the wrapper are not necessarily appropriate
   when it is reused as an external toolchain. For instance, ccache
   may have been enabled while building the toolchain but not when
   using it as an external toolchain.

2. Currently, the wrapper expects to reside in .../usr/bin, but when
   used as an external toolchain it will be in .../ext-toolchain/bin.
   Therefore, the wrapper can't find the real binary and sysroot
   anymore.

To bypass the wrapper, we check for the existence of *.br_real files in
the external toolchain directory. If any such file exists, the wrapper
will add the .br_real suffix for all the wrapped files. Note that the
wrapper doesn't check if the *.br_real exists for each individual
wrapped file, it just assumes that all wrapped files have a
corresponding .br_real. This is currently true but that may change in
the future of course.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
Peter, you requested the check to be in the .mk file rather than in
the wrapper. However, since we have only one wrapper for all wrapped
files, that means that either all of them or none of them should have
the .br_real suffix. Therefore, if we later wrap additional files
(e.g. ld), existing external buildroot toolchains will fail again. So
to fix that, there should be a check in the wrapper.c file itself. But
if we have a check in the wrapper.c, there's no point having a check in
the wrapper.mk as well... So Peter, please tell me if I should instead
drop the check in the .mk file and add one in the .c file. Note that
that can be done as a follow-up so it shouldn't block this patch.

Lightly tested with an internal toolchain, an external Sourcery
toolchain, an external downloaded buildroot toolchain, and an external
pre-installed buildroot toolchain.
---
 toolchain/toolchain-external/toolchain-external.mk | 14 +++++++++++---
 toolchain/toolchain-wrapper.c                      |  6 +++---
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk
index 3fb165c..4e12a1c 100644
--- a/toolchain/toolchain-external/toolchain-external.mk
+++ b/toolchain/toolchain-external/toolchain-external.mk
@@ -149,10 +149,18 @@ TOOLCHAIN_EXTERNAL_BIN := $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/bin
 endif
 endif
 
+# If this is a buildroot toolchain, it already has a wrapper which we want to
+# bypass. Since this is only evaluated after it has been extracted, we can use
+# $(wildcard ...) here.
+TOOLCHAIN_EXTERNAL_SUFFIX = \
+	$(if $(wildcard $(TOOLCHAIN_EXTERNAL_BIN)/*.br_real),.br_real)
+TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += \
+	-DBR_CROSS_PATH_SUFFIX='"$(TOOLCHAIN_EXTERNAL_SUFFIX)"'
+
 TOOLCHAIN_EXTERNAL_CROSS = $(TOOLCHAIN_EXTERNAL_BIN)/$(TOOLCHAIN_EXTERNAL_PREFIX)-
-TOOLCHAIN_EXTERNAL_CC = $(TOOLCHAIN_EXTERNAL_CROSS)gcc
-TOOLCHAIN_EXTERNAL_CXX = $(TOOLCHAIN_EXTERNAL_CROSS)g++
-TOOLCHAIN_EXTERNAL_READELF = $(TOOLCHAIN_EXTERNAL_CROSS)readelf
+TOOLCHAIN_EXTERNAL_CC = $(TOOLCHAIN_EXTERNAL_CROSS)gcc$(TOOLCHAIN_EXTERNAL_SUFFIX)
+TOOLCHAIN_EXTERNAL_CXX = $(TOOLCHAIN_EXTERNAL_CROSS)g++$(TOOLCHAIN_EXTERNAL_SUFFIX)
+TOOLCHAIN_EXTERNAL_READELF = $(TOOLCHAIN_EXTERNAL_CROSS)readelf$(TOOLCHAIN_EXTERNAL_SUFFIX)
 
 ifeq ($(filter $(HOST_DIR)/%,$(TOOLCHAIN_EXTERNAL_BIN)),)
 # TOOLCHAIN_EXTERNAL_BIN points outside HOST_DIR => absolute path
diff --git a/toolchain/toolchain-wrapper.c b/toolchain/toolchain-wrapper.c
index 632696c..16a3d78 100644
--- a/toolchain/toolchain-wrapper.c
+++ b/toolchain/toolchain-wrapper.c
@@ -143,10 +143,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);
+	ret = snprintf(path, sizeof(path), "%s/" BR_CROSS_PATH_REL "/%s" BR_CROSS_PATH_SUFFIX, absbasedir, basename);
 #elif defined(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), BR_CROSS_PATH_ABS "/%s" BR_CROSS_PATH_SUFFIX, basename);
+#else
 	ret = snprintf(path, sizeof(path), "%s/usr/bin/%s" BR_CROSS_PATH_SUFFIX, absbasedir, basename);
 #endif
 	if (ret >= sizeof(path)) {
-- 
2.5.3

[Buildroot] [PATCH 2/2] toolchain-external: bypass buildroot wrapper

[Thomas Petazzoni]

Arnout,

On Wed, 14 Oct 2015 23:05:55 +0200, Arnout Vandecappelle
(Essensium/Mind) wrote:

> Lightly tested with an internal toolchain, an external Sourcery
> toolchain, an external downloaded buildroot toolchain, and an external
> pre-installed buildroot toolchain.

Did you test with a pre-existing Buildroot toolchain (i.e that predates
the introduction of the wrapper for internal toolchain), or did you
build a Buildroot toolchain with the latest Buildroot (including your
patches) and then re-used it as an external toolchain in another
Buildroot configuration ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/2] toolchain-external: bypass buildroot wrapper

[Arnout Vandecappelle]

On 14-10-15 23:31, Thomas Petazzoni wrote:
> Arnout,
> 
> On Wed, 14 Oct 2015 23:05:55 +0200, Arnout Vandecappelle
> (Essensium/Mind) wrote:
> 
>> Lightly tested with an internal toolchain, an external Sourcery
>> toolchain, an external downloaded buildroot toolchain, and an external
>> pre-installed buildroot toolchain.
> 
> Did you test with a pre-existing Buildroot toolchain (i.e that predates
> the introduction of the wrapper for internal toolchain), or did you
> build a Buildroot toolchain with the latest Buildroot (including your
> patches) and then re-used it as an external toolchain in another
> Buildroot configuration ?

 I built a toolchain with buildroot, i.e. including wrapper and .br_real, tarred
it and downloaded it.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 1/2] gcc: use '.br_real' instead of '.real' for the wrapped toolchain

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> writes:

I find the subject quite hard to understand. The .real / .br_real is
not for the WRAPPED toolchain, but for the RAW toolchain binaries.

 > If an externally built toolchain also wraps the toolchain executables,
 > there is a risk that it will also use the '.real' extension. To
 > minimise this risk, use a more buildroot-specific extension instead:
 > '.br_real'.

 > For the time being, this is not yet a problem since the internal
 > toolchain never has such a wrapper. However, in a later commit we
 > will bypass the buildroot wrapper for external toolchains, so we
 > have to avoid doing that when it's not buildroot that wrapped it.

I'm not sure what you mean here. We DO have a a wrapper for the internal
toolchain.

Committed with the description reworded, thanks!

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 2/2] toolchain-external: bypass buildroot wrapper

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> writes:

 > The buildroot internal toolchain now adds a wrapper. When we use a
 > buildroot toolchain as an external toolchain, we want to bypass this
 > wrapper and call the compiler directly, for two reasons:

 > 1. The options added by the wrapper are not necessarily appropriate
 >    when it is reused as an external toolchain. For instance, ccache
 >    may have been enabled while building the toolchain but not when
 >    using it as an external toolchain.

 > 2. Currently, the wrapper expects to reside in .../usr/bin, but when
 >    used as an external toolchain it will be in .../ext-toolchain/bin.
 >    Therefore, the wrapper can't find the real binary and sysroot
 >    anymore.

 > To bypass the wrapper, we check for the existence of *.br_real files in
 > the external toolchain directory. If any such file exists, the wrapper
 > will add the .br_real suffix for all the wrapped files. Note that the
 > wrapper doesn't check if the *.br_real exists for each individual
 > wrapped file, it just assumes that all wrapped files have a
 > corresponding .br_real. This is currently true but that may change in
 > the future of course.

 > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
 > ---
 > Peter, you requested the check to be in the .mk file rather than in
 > the wrapper. However, since we have only one wrapper for all wrapped
 > files, that means that either all of them or none of them should have
 > the .br_real suffix. Therefore, if we later wrap additional files
 > (e.g. ld), existing external buildroot toolchains will fail again. So
 > to fix that, there should be a check in the wrapper.c file itself. But
 > if we have a check in the wrapper.c, there's no point having a check in
 > the wrapper.mk as well... So Peter, please tell me if I should instead
 > drop the check in the .mk file and add one in the .c file. Note that
 > that can be done as a follow-up so it shouldn't block this patch.

Yeah, that's true. Either that or we need to add more complication to
the .mk file. I'll need to think a bit more about that.

In the mean time - Committed, thanks.

-- 
Venlig hilsen,
Peter Korsgaard