From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] toolchain: improve musl check to support static toolchains
Date: Sat, 7 Jul 2018 13:56:17 +0200 [thread overview]
Message-ID: <20180707115617.GA2507@scaer> (raw)
In-Reply-To: <2a850fef-a581-170d-0945-e8a4182b4347@mind.be>
On 2018-07-06 00:25 +0200, Arnout Vandecappelle spake thusly:
>
>
> On 04-07-18 23:42, Thomas Petazzoni wrote:
> > 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.
>
> 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.
> 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
>
> >
> > 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 <thomas.petazzoni@bootlin.com>
> > ---
> > toolchain/helpers.mk | 9 +++------
> > toolchain/toolchain-external/pkg-toolchain-external.mk | 3 +--
> > 2 files changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
> > index 1792286add..e5520c00c3 100644
> > --- a/toolchain/helpers.mk
> > +++ b/toolchain/helpers.mk
> > @@ -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
> > diff --git a/toolchain/toolchain-external/pkg-toolchain-external.mk b/toolchain/toolchain-external/pkg-toolchain-external.mk
> > index 8b2c283654..02d992531d 100644
> > --- a/toolchain/toolchain-external/pkg-toolchain-external.mk
> > +++ b/toolchain/toolchain-external/pkg-toolchain-external.mk
> > @@ -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
> >
>
> --
> 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
--
.-----------------.--------------------.------------------.--------------------.
| 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-07-07 11:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-04 21:42 [Buildroot] [PATCH] toolchain: improve musl check to support static toolchains Thomas Petazzoni
2018-07-05 2:54 ` Baruch Siach
2018-07-05 7:58 ` Thomas Petazzoni
2018-07-05 22:25 ` Arnout Vandecappelle
2018-07-06 7:36 ` Thomas Petazzoni
2018-07-07 11:56 ` Yann E. MORIN [this message]
2018-07-13 7:23 ` Peter Korsgaard
2018-07-16 22:11 ` Arnout Vandecappelle
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=20180707115617.GA2507@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox