All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] toolchain: improve musl check to support static toolchains
Date: Thu, 5 Jul 2018 09:58:41 +0200	[thread overview]
Message-ID: <20180705095841.1d115a1a@windsurf> (raw)
In-Reply-To: <20180705025418.dkit5uzdtwfezkgc@tarshish>

Hello,

On Thu, 5 Jul 2018 05:54:18 +0300, Baruch Siach wrote:

> On Wed, Jul 04, 2018 at 11:42:57PM +0200, 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.
> > 
> > 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
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2018-07-05  7:58 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 [this message]
2018-07-05 22:25 ` Arnout Vandecappelle
2018-07-06  7:36   ` Thomas Petazzoni
2018-07-07 11:56   ` Yann E. MORIN
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=20180705095841.1d115a1a@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --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.