[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140403034027.GA7743@light-speed.de>
Date: Thu, 3 Apr 2014 05:40:27 +0200
From: Jens Tröger <jens.troeger@...ht-speed.de>
To: musl@...ts.openwall.com
Subject: Re: Building musl 1.0.0 with LLVM/clang 3.4
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/
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.
