Skip to contentSkip to conversation

toolchain: improve musl check to support static toolchains

PATCH New Thomas Petazzoni 5 participants 8 messages Jul 4, 2018 – Jul 16, 2018

lore
Share & tools
lore

Thomas Petazzoni

author
#0 lore raw

PATCH 1/1 toolchain: improve musl check to support static toolchains

The check_musl function currently builds a program and verifies if the program interpreter starts with /lib/ld-musl. While this works fine for dynamically linked programs, this obviously doesn't work for a purely static musl toolchain such as [1].

There is no easy way to identify a toolchain as using the musl C library. For glibc, dynamic linking is always supported, so we look at the dynamic linker name. For uClibc, there is a distinctive uClibc_config.h header file. There is no such distinctive feature in musl.

We end up resorting to looking for the string MUSL_LOCPATH, which is used by musl locale_map.c source file. This string has been present in musl since 2014. It certainly isn't a very stable or convincing solution to identify the C library as being musl, but it's the best we could find.

Note that we are sure there is a libc.a file, because the check_unusable_toolchain function checks that there is a such a file.

[1] http://autobuild.buildroot.net/toolchains/tarballs/br-arm-musl-static-2018.05.tar.bz2

Signed-off-by Thomas Petazzoni <[email protected]>
---
 toolchain/helpers.mk                                   | 9 +++------
 toolchain/toolchain-external/pkg-toolchain-external.mk | 3 +--
 2 files changed, 4 insertions(+), 8 deletions(-)
toolchain/helpers.mk +3 -6
index 1792286add..e5520c00c3 100644
@@ -241,14 +241,11 @@ check_glibc = \
 # $2: cross-readelf path
 check_musl = \
 	__CROSS_CC=$(strip $1) ; \
-	__CROSS_READELF=$(strip $2) ; \
-	echo 'void main(void) {}' | $${__CROSS_CC} -x c -o $(BUILD_DIR)/.br-toolchain-test.tmp - >/dev/null 2>&1; \
-	if ! $${__CROSS_READELF} -l $(BUILD_DIR)/.br-toolchain-test.tmp 2> /dev/null | grep 'program interpreter: /lib/ld-musl' -q; then \
-		rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*; \
+	libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
+	if ! strings $${libc_a_path} | grep -q MUSL_LOCPATH ; then \
 		echo "Incorrect selection of the C library" ; \
 		exit -1; \
-	fi ; \
-	rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
+	fi
 
 #
 # Check the conformity of Buildroot configuration with regard to the
toolchain/toolchain-external/pkg-toolchain-external.mk +1 -2
index 8b2c283654..02d992531d 100644
@@ -557,8 +557,7 @@ define $(2)_CONFIGURE_CMDS
 		$$(call check_uclibc,$$$${SYSROOT_DIR}) ; \
 	elif test "$$(BR2_TOOLCHAIN_EXTERNAL_MUSL)" = "y" ; then \
 		$$(call check_musl,\
-			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)",\
-			$$(TOOLCHAIN_EXTERNAL_READELF)) ; \
+			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)") ; \
 	else \
 		$$(call check_glibc,$$$${SYSROOT_DIR}) ; \
 	fi
Signature · 1 line
2.14.4
#1 lore raw

PATCH 1/1 toolchain: improve musl check to support static toolchains

Hi Thomas,

Quoted 11 lines · Thomas Petazzoni

The check_musl function currently builds a program and verifies if the program interpreter starts with /lib/ld-musl. While this works fine for dynamically linked programs, this obviously doesn't work for a purely static musl toolchain such as [1].

There is no easy way to identify a toolchain as using the musl C library. For glibc, dynamic linking is always supported, so we look at the dynamic linker name. For uClibc, there is a distinctive uClibc_config.h header file. There is no such distinctive feature in musl.

Quoted 8 lines

We end up resorting to looking for the string MUSL_LOCPATH, which is used by musl locale_map.c source file. This string has been present in musl since 2014. It certainly isn't a very stable or convincing solution to identify the C library as being musl, but it's the best we could find.

Note that we are sure there is a libc.a file, because the check_unusable_toolchain function checks that there is a such a file.

So the check should work even for dynamic only toolchains, right?

Quoted 13 lines

[1] http://autobuild.buildroot.net/toolchains/tarballs/br-arm-musl-static-2018.05.tar.bz2

Signed-off-by Thomas Petazzoni <[email protected]>
---
 toolchain/helpers.mk                                   | 9 +++------
 toolchain/toolchain-external/pkg-toolchain-external.mk | 3 +--
 2 files changed, 4 insertions(+), 8 deletions(-)
toolchain/helpers.mk +0 -0
index 1792286add..e5520c00c3 100644

toolchain/helpers.mk check_glibc = \ · line 241

Quoted 1 line
toolchain/helpers.mk +0 -0
@@ -241,14 +241,11 @@ check_glibc = \
 # $2: cross-readelf path

This comment is redundant now.

Quoted 21 lines
toolchain/helpers.mk +3 -6
 check_musl = \
 	__CROSS_CC=$(strip $1) ; \
-	__CROSS_READELF=$(strip $2) ; \
-	echo 'void main(void) {}' | $${__CROSS_CC} -x c -o $(BUILD_DIR)/.br-toolchain-test.tmp - >/dev/null 2>&1; \
-	if ! $${__CROSS_READELF} -l $(BUILD_DIR)/.br-toolchain-test.tmp 2> /dev/null | grep 'program interpreter: /lib/ld-musl' -q; then \
-		rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*; \
+	libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
+	if ! strings $${libc_a_path} | grep -q MUSL_LOCPATH ; then \
 		echo "Incorrect selection of the C library" ; \
 		exit -1; \
-	fi ; \
-	rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
+	fi
 
 #
 # Check the conformity of Buildroot configuration with regard to the
toolchain/toolchain-external/pkg-toolchain-external.mk +0 -0
index 8b2c283654..02d992531d 100644

toolchain/toolchain-external/pkg-toolchain-external.mk define $(2)_CONFIGURE_CMDS · line 563

Quoted 9 lines
toolchain/toolchain-external/pkg-toolchain-external.mk +1 -2
@@ -557,8 +557,7 @@ define $(2)_CONFIGURE_CMDS
 		$$(call check_uclibc,$$$${SYSROOT_DIR}) ; \
 	elif test "$$(BR2_TOOLCHAIN_EXTERNAL_MUSL)" = "y" ; then \
 		$$(call check_musl,\
-			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)",\
-			$$(TOOLCHAIN_EXTERNAL_READELF)) ; \
+			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)") ; \
 	else \
 		$$(call check_glibc,$$$${SYSROOT_DIR}) ; \
 	fi

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
author
#2 lore raw

PATCH 1/1 toolchain: improve musl check to support static toolchains

Hello,

Quoted 18 lines · Baruch Siach
Quoted 17 lines · Thomas Petazzoni

The check_musl function currently builds a program and verifies if the program interpreter starts with /lib/ld-musl. While this works fine for dynamically linked programs, this obviously doesn't work for a purely static musl toolchain such as [1].

There is no easy way to identify a toolchain as using the musl C library. For glibc, dynamic linking is always supported, so we look at the dynamic linker name. For uClibc, there is a distinctive uClibc_config.h header file. There is no such distinctive feature in musl.

We end up resorting to looking for the string MUSL_LOCPATH, which is used by musl locale_map.c source file. This string has been present in musl since 2014. It certainly isn't a very stable or convincing solution to identify the C library as being musl, but it's the best we could find.

Quoted 4 lines
Quoted 2 lines

Note that we are sure there is a libc.a file, because the check_unusable_toolchain function checks that there is a such a file.

So the check should work even for dynamic only toolchains, right?

Yes, it should. I just verified by building a dynamic only musl toolchain and a dynamic only uclibc toolchain, and then do have libc.a:

MUSL:

$ grep BR2_SHARED_LIBS .config
BR2_SHARED_LIBS=y
$ find host/ -name 'libc.a'
host/arm-buildroot-linux-musleabi/sysroot/lib/libc.a
$ strings host/arm-buildroot-linux-musleabi/sysroot/lib/libc.a | grep MUSL_LOCPATH
MUSL_LOCPATH

UCLIBC:

$ grep BR2_SHARED_LIBS .config
BR2_SHARED_LIBS=y
$ find host/ -name 'libc.a'
host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libc.a

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#3 lore raw

PATCH 1/1 toolchain: improve musl check to support static toolchains

In reply to Thomas Petazzoni
Quoted 11 lines · Thomas Petazzoni

The check_musl function currently builds a program and verifies if the program interpreter starts with /lib/ld-musl. While this works fine for dynamically linked programs, this obviously doesn't work for a purely static musl toolchain such as [1].

There is no easy way to identify a toolchain as using the musl C library. For glibc, dynamic linking is always supported, so we look at the dynamic linker name. For uClibc, there is a distinctive uClibc_config.h header file. There is no such distinctive feature in musl.

Quoted 5 lines

We end up resorting to looking for the string MUSL_LOCPATH, which is used by musl locale_map.c source file. This string has been present in musl since 2014. It certainly isn't a very stable or convincing solution to identify the C library as being musl, but it's the best we could find.

Well, the most obvious indicator is the output of gcc -dumpmachine... Is there
any reason why we wouldn't be able to treat that as reliable? AFAIU, hundreds of autotools package will fail if the dumpmachine tuple is not something sane...

BTW, we do all these checks for libc etc., but we don't even check for the
architecture... E.g. trying to use an arm compiler with BR2_armeb gives the rather unhelpful:

Cannot execute cross-compiler '.../opt/ext-toolchain/bin/armeb-linux-gcc.br_real'

So, if you're a little bit savvy, you notice that the toolchain prefix is wrong, so you set BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX to arm-linux- instead of $(ARCH)-linux. And it all works! Happily generating little-endian binaries...

Bottom line: perhaps we should just check the tuple. That way we check the
arch, we check that it's a hosted linux toolchain, we check libc, and we can even check the ARM ABI, all in one fell swoop...

Regards,
Arnout

Quoted 49 lines

Note that we are sure there is a libc.a file, because the check_unusable_toolchain function checks that there is a such a file.

[1] http://autobuild.buildroot.net/toolchains/tarballs/br-arm-musl-static-2018.05.tar.bz2

Signed-off-by Thomas Petazzoni <[email protected]>
---
 toolchain/helpers.mk                                   | 9 +++------
 toolchain/toolchain-external/pkg-toolchain-external.mk | 3 +--
 2 files changed, 4 insertions(+), 8 deletions(-)
toolchain/helpers.mk +3 -6
index 1792286add..e5520c00c3 100644
@@ -241,14 +241,11 @@ check_glibc = \
 # $2: cross-readelf path
 check_musl = \
 	__CROSS_CC=$(strip $1) ; \
-	__CROSS_READELF=$(strip $2) ; \
-	echo 'void main(void) {}' | $${__CROSS_CC} -x c -o $(BUILD_DIR)/.br-toolchain-test.tmp - >/dev/null 2>&1; \
-	if ! $${__CROSS_READELF} -l $(BUILD_DIR)/.br-toolchain-test.tmp 2> /dev/null | grep 'program interpreter: /lib/ld-musl' -q; then \
-		rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*; \
+	libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
+	if ! strings $${libc_a_path} | grep -q MUSL_LOCPATH ; then \
 		echo "Incorrect selection of the C library" ; \
 		exit -1; \
-	fi ; \
-	rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
+	fi
 
 #
 # Check the conformity of Buildroot configuration with regard to the
toolchain/toolchain-external/pkg-toolchain-external.mk +1 -2
index 8b2c283654..02d992531d 100644
@@ -557,8 +557,7 @@ define $(2)_CONFIGURE_CMDS
 		$$(call check_uclibc,$$$${SYSROOT_DIR}) ; \
 	elif test "$$(BR2_TOOLCHAIN_EXTERNAL_MUSL)" = "y" ; then \
 		$$(call check_musl,\
-			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)",\
-			$$(TOOLCHAIN_EXTERNAL_READELF)) ; \
+			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)") ; \
 	else \
 		$$(call check_glibc,$$$${SYSROOT_DIR}) ; \
 	fi
Signature · 6 lines
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
author
#4 lore raw

PATCH 1/1 toolchain: improve musl check to support static toolchains

Hello,

Quoted 10 lines · Arnout Vandecappelle

Well, the most obvious indicator is the output of gcc -dumpmachine... Is there
any reason why we wouldn't be able to treat that as reliable? AFAIU, hundreds of autotools package will fail if the dumpmachine tuple is not something sane...

BTW, we do all these checks for libc etc., but we don't even check for the
architecture... E.g. trying to use an arm compiler with BR2_armeb gives the rather unhelpful:

Cannot execute cross-compiler '.../opt/ext-toolchain/bin/armeb-linux-gcc.br_real'

Quoted 7 lines

So, if you're a little bit savvy, you notice that the toolchain prefix is wrong, so you set BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX to arm-linux- instead of $(ARCH)-linux. And it all works! Happily generating little-endian binaries...

Bottom line: perhaps we should just check the tuple. That way we check the
arch, we check that it's a hosted linux toolchain, we check libc, and we can even check the ARM ABI, all in one fell swoop...

That's a good idea indeed.

Another thing I noticed is that we don't check the static/shared capabilities of the toolchain. For example if you try to use a static-only external toolchain, by you keep the default of BR2_SHARED_LIBS=y, things don't work very well.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#5 lore raw

PATCH 1/1 toolchain: improve musl check to support static toolchains

In reply to Arnout Vandecappelle

On 2018-07-06 00:25 +0200, Arnout Vandecappelle spake thusly:

Quoted 20 lines · Thomas Petazzoni
Quoted 11 lines

The check_musl function currently builds a program and verifies if the program interpreter starts with /lib/ld-musl. While this works fine for dynamically linked programs, this obviously doesn't work for a purely static musl toolchain such as [1].

There is no easy way to identify a toolchain as using the musl C library. For glibc, dynamic linking is always supported, so we look at the dynamic linker name. For uClibc, there is a distinctive uClibc_config.h header file. There is no such distinctive feature in musl.

Quoted 5 lines

We end up resorting to looking for the string MUSL_LOCPATH, which is used by musl locale_map.c source file. This string has been present in musl since 2014. It certainly isn't a very stable or convincing solution to identify the C library as being musl, but it's the best we could find.

Quoted 3 lines

Well, the most obvious indicator is the output of gcc -dumpmachine... Is there
any reason why we wouldn't be able to treat that as reliable? AFAIU, hundreds of autotools package will fail if the dumpmachine tuple is not something sane...

Does that still output the correct tupple for multilib toolchains?

For example, the mips-2016.05-8-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2 toolchain is a big-multi-lib toolchain, with both glibc and uclibc, but it always returns mips-linux-gnu, even when either is explicitly requested:

    $ ./mips-2016.05/bin/mips-linux-gnu-gcc -dumpmachine
    mips-linux-gnu
    $ ./mips-2016.05/bin/mips-linux-gnu-gcc -mglibc -dumpmachine
    mips-linux-gnu
    $ ./mips-2016.05/bin/mips-linux-gnu-gcc -muclibc -dumpmachine
    mips-linux-gnu

So that unfortunately does not work... :-(

Regards,
Yann E. MORIN.

Quoted 74 lines

BTW, we do all these checks for libc etc., but we don't even check for the
architecture... E.g. trying to use an arm compiler with BR2_armeb gives the rather unhelpful:

Cannot execute cross-compiler '.../opt/ext-toolchain/bin/armeb-linux-gcc.br_real'

So, if you're a little bit savvy, you notice that the toolchain prefix is wrong, so you set BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX to arm-linux- instead of $(ARCH)-linux. And it all works! Happily generating little-endian binaries...

Bottom line: perhaps we should just check the tuple. That way we check the
arch, we check that it's a hosted linux toolchain, we check libc, and we can even check the ARM ABI, all in one fell swoop...

Regards,
Arnout

Quoted 49 lines

Note that we are sure there is a libc.a file, because the check_unusable_toolchain function checks that there is a such a file.

[1] http://autobuild.buildroot.net/toolchains/tarballs/br-arm-musl-static-2018.05.tar.bz2

Signed-off-by Thomas Petazzoni <[email protected]>
---
 toolchain/helpers.mk                                   | 9 +++------
 toolchain/toolchain-external/pkg-toolchain-external.mk | 3 +--
 2 files changed, 4 insertions(+), 8 deletions(-)
toolchain/helpers.mk +3 -6
index 1792286add..e5520c00c3 100644
@@ -241,14 +241,11 @@ check_glibc = \
 # $2: cross-readelf path
 check_musl = \
 	__CROSS_CC=$(strip $1) ; \
-	__CROSS_READELF=$(strip $2) ; \
-	echo 'void main(void) {}' | $${__CROSS_CC} -x c -o $(BUILD_DIR)/.br-toolchain-test.tmp - >/dev/null 2>&1; \
-	if ! $${__CROSS_READELF} -l $(BUILD_DIR)/.br-toolchain-test.tmp 2> /dev/null | grep 'program interpreter: /lib/ld-musl' -q; then \
-		rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*; \
+	libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
+	if ! strings $${libc_a_path} | grep -q MUSL_LOCPATH ; then \
 		echo "Incorrect selection of the C library" ; \
 		exit -1; \
-	fi ; \
-	rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
+	fi
 
 #
 # Check the conformity of Buildroot configuration with regard to the
toolchain/toolchain-external/pkg-toolchain-external.mk +1 -2
index 8b2c283654..02d992531d 100644
@@ -557,8 +557,7 @@ define $(2)_CONFIGURE_CMDS
 		$$(call check_uclibc,$$$${SYSROOT_DIR}) ; \
 	elif test "$$(BR2_TOOLCHAIN_EXTERNAL_MUSL)" = "y" ; then \
 		$$(call check_musl,\
-			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)",\
-			$$(TOOLCHAIN_EXTERNAL_READELF)) ; \
+			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)") ; \
 	else \
 		$$(call check_glibc,$$$${SYSROOT_DIR}) ; \
 	fi
Signature · 6 lines
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
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#6 lore raw

PATCH 1/1 toolchain: improve musl check to support static toolchains

Quoted 13 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Well, the most obvious indicator is the output of gcc -dumpmachine... Is there any reason why we wouldn't be able to treat that as reliable? AFAIU, hundreds of autotools package will fail if the dumpmachine tuple is not something sane...

Does that still output the correct tupple for multilib toolchains?

For example, the mips-2016.05-8-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2 toolchain is a big-multi-lib toolchain, with both glibc and uclibc, but it always returns mips-linux-gnu, even when either is explicitly requested:

Quoted 8 lines
    $ ./mips-2016.05/bin/mips-linux-gnu-gcc -dumpmachine
    mips-linux-gnu
    $ ./mips-2016.05/bin/mips-linux-gnu-gcc -mglibc -dumpmachine
    mips-linux-gnu
    $ ./mips-2016.05/bin/mips-linux-gnu-gcc -muclibc -dumpmachine
    mips-linux-gnu

So that unfortunately does not work... :-(

*Grumble* It looked so nice and simple :/

Signature · 1 line
Bye, Peter Korsgaard
#7 lore raw

PATCH 1/1 toolchain: improve musl check to support static toolchains

In reply to Thomas Petazzoni
Quoted 17 lines · Thomas Petazzoni

The check_musl function currently builds a program and verifies if the program interpreter starts with /lib/ld-musl. While this works fine for dynamically linked programs, this obviously doesn't work for a purely static musl toolchain such as [1].

There is no easy way to identify a toolchain as using the musl C library. For glibc, dynamic linking is always supported, so we look at the dynamic linker name. For uClibc, there is a distinctive uClibc_config.h header file. There is no such distinctive feature in musl.

We end up resorting to looking for the string MUSL_LOCPATH, which is used by musl locale_map.c source file. This string has been present in musl since 2014. It certainly isn't a very stable or convincing solution to identify the C library as being musl, but it's the best we could find.

Quoted 6 lines

Note that we are sure there is a libc.a file, because the check_unusable_toolchain function checks that there is a such a file.

[1] http://autobuild.buildroot.net/toolchains/tarballs/br-arm-musl-static-2018.05.tar.bz2

Signed-off-by Thomas Petazzoni <[email protected]>

I looked long and hard for a better alternative, but I couldn't find anything.
I also thought of testing whether __GLIBC__ is defined, but that's not very stable either (any non-musl library that doesn't define __GLIBC__, including bionic and newlib, would also be detected as musl).

Therefore:

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Regards,
Arnout

Quoted 42 lines
---
 toolchain/helpers.mk                                   | 9 +++------
 toolchain/toolchain-external/pkg-toolchain-external.mk | 3 +--
 2 files changed, 4 insertions(+), 8 deletions(-)
toolchain/helpers.mk +3 -6
index 1792286add..e5520c00c3 100644
@@ -241,14 +241,11 @@ check_glibc = \
 # $2: cross-readelf path
 check_musl = \
 	__CROSS_CC=$(strip $1) ; \
-	__CROSS_READELF=$(strip $2) ; \
-	echo 'void main(void) {}' | $${__CROSS_CC} -x c -o $(BUILD_DIR)/.br-toolchain-test.tmp - >/dev/null 2>&1; \
-	if ! $${__CROSS_READELF} -l $(BUILD_DIR)/.br-toolchain-test.tmp 2> /dev/null | grep 'program interpreter: /lib/ld-musl' -q; then \
-		rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*; \
+	libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
+	if ! strings $${libc_a_path} | grep -q MUSL_LOCPATH ; then \
 		echo "Incorrect selection of the C library" ; \
 		exit -1; \
-	fi ; \
-	rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
+	fi
 
 #
 # Check the conformity of Buildroot configuration with regard to the
toolchain/toolchain-external/pkg-toolchain-external.mk +1 -2
index 8b2c283654..02d992531d 100644
@@ -557,8 +557,7 @@ define $(2)_CONFIGURE_CMDS
 		$$(call check_uclibc,$$$${SYSROOT_DIR}) ; \
 	elif test "$$(BR2_TOOLCHAIN_EXTERNAL_MUSL)" = "y" ; then \
 		$$(call check_musl,\
-			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)",\
-			$$(TOOLCHAIN_EXTERNAL_READELF)) ; \
+			"$$(TOOLCHAIN_EXTERNAL_CC) $$(TOOLCHAIN_EXTERNAL_CFLAGS)") ; \
 	else \
 		$$(call check_glibc,$$$${SYSROOT_DIR}) ; \
 	fi
Signature · 6 lines
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