[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 3 Apr 2014 00:19:52 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Building musl 1.0.0 with LLVM/clang 3.4
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
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.
