Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Apr 2014 05:40:27 +0200
From: Jens Tröger <>
Subject: Re: Building musl 1.0.0 with LLVM/clang 3.4

On Wed, Apr 02, 2014 at 11:21:21PM -0400, Rich Felker wrote:
> On Thu, Apr 03, 2014 at 04:10:43AM +0200, Jens Tröger wrote:
> > Hi,
> > 
> > I needed the bitcode files for libc functions, so compiling musl with
> > clang was the ideal option.  I'm using off-the-shelf LLVM 3.4
> > 
> > However, I had to tweak the configure script in order run it.  In line
> > 243 it sets some compiler options
> > 
> >   tryflag CFLAGS_C99FSE -nostdinc
> >   
> > which in turn prevents the "checking whether compiler's long double
> > definition matches float.h... no" from succeeding.  That is because the
> > <float.h> can't be found.  I found a few posts online which fixed
> > similar issues by removing this flag for clang.
> This is not the right solution. musl does not use float.h, etc.
> provided by the compiler, and the compiler-provided ones are
> incompatible in at least subtle ways. The correct float.h is in the
> musl source tree, split between a base file in ./include and an
> arch-specific file in ./arch/$ARCH/bits.

I was premature.  The configure script uses -I./arch and -I./include
which are "hardwired" paths assuming that configure runs inside the musl
folder.  However, I usually separate src and build folder, and then call
out from the build folder into the source folder.  So, whereas my

  src/musl-1.0.0 > CC=clang CFLAGS=-emit-llvm ./configure

works, this won't:

  build/musl-1.0.0 > CC=clang CFLAGS=-emit-llvm ../../src/musl-1.0.0/configure

> If you get that message from configure, it probably means your
> compiler is providing a different definition of long double that what
> musl expects for the given arch, and just changing which float.h gets
> used is not going to solve the problem but bury it.

With my initial configure run, there wasn't any <float.h> and removing
-nostdinc from clang fell back to the system includes.

As you said, not appropriate and just obscures the issue.  I am now
building inside the source folder.

> Could you elaborate on what arch you're building for? If there is no
> arch, just abstract "bitcode" not associated with any given arch, you
> need to make a new pseudo-arch for this setup, and define how it
> communicates with the underlying system/environment via an appropriate
> syscall_arch.h file, among other things (such as an appropriate
> bits/float.h file).

The --target is x86_64-unknown-linux and musl builds fine for that.
Using the -emit-llvm option I also get the bitcode files, which is what
I care about.
> > Once configure ran through, I could generate bitcode files for almost
> > all of libc (minus the assembly files, of course).
> > 
> > There were warnings though, and I wonder: are they of interest?  Is
> > there intention to fix them?  Just asking because I'm very particular
> > about warnings, and I usually compile my code with
> > 
> >   -Wall -Wextra -pedantic
> > 
> > and then selectively quieten warnings.
> Maybe. The configure script has an --enable-warnings option which
> turns on all the warnings we care about and silences the spammy ones,
> at least for gcc, but it may miss some for clang.

I'm happy to forward the warnings :-)

> Rich


Jens Tröger

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.