Date: Wed, 2 Apr 2014 23:21:21 -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 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
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.