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.