Building musl 1.0.0 with LLVM/clang 3.4

Building musl 1.0.0 with LLVM/clang 3.4

[Jens Tröger]

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.

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.

Cheers,
Jens

-- 
Jens Tröger
http://savage.light-speed.de/

Re: Building musl 1.0.0 with LLVM/clang 3.4

[Rich Felker]

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.

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.

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).

> 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.

Rich

Re: Building musl 1.0.0 with LLVM/clang 3.4

[Jens Tröger]

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

-- 
Jens Tröger
http://savage.light-speed.de/

Re: Building musl 1.0.0 with LLVM/clang 3.4

[Rich Felker]

On Thu, Apr 03, 2014 at 05:40:27AM +0200, Jens Tröger wrote:
> 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

Yes, there's actually an in-progress patch for supporting out-of-tree
builds, but it's not mature enough for inclusion yet. I suppose the
documentation should mention somewhere that out-of-tree builds are not
yet supported.

> > > 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 :-)

If there are warnings when --enable-warnings is used, let me know what
-W's they fall under so we can disable them. :-) I think llvm/clang
has different defaults than gcc (and maybe more things included under
-Wall) so I suspect configure isn't switching off the ones it should
for clang.

Rich