[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140403032121.GP26358@brightrain.aerifal.cx>
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.
