From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4775 Path: news.gmane.org!not-for-mail From: Jens =?iso-8859-15?Q?Tr=F6ger?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: Building musl 1.0.0 with LLVM/clang 3.4 Date: Thu, 3 Apr 2014 05:40:27 +0200 Message-ID: <20140403034027.GA7743@light-speed.de> References: <20140403021043.GA32626@light-speed.de> <20140403032121.GP26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1396528831 17647 80.91.229.3 (3 Apr 2014 12:40:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 12:40:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4777-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 03 14:40:26 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WVfB4-000731-NP for gllmg-musl@plane.gmane.org; Thu, 03 Apr 2014 12:47:22 +0200 Original-Received: (qmail 13985 invoked by uid 550); 3 Apr 2014 03:40:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13977 invoked from network); 3 Apr 2014 03:40:40 -0000 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at mail.light-speed.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=light-speed.de; s=mail; t=1396496428; bh=F3joexahWUe3g8L+JzxB6p9FiK4Cmg9TRnTcKnd5YjY=; h=Date:From:To:Subject:References:In-Reply-To; b=CLRy4Bjk6yaSdr+k3BO7KWuD45djrjeXsxbyJAc9K6tEuGF4p30Lj9kECFEZS5jpG unczIHvbwyYUqpTcVasyKsnc3+QMXbzRO1JutJ5j3aCndBxUS29CTpm86hMIfGdXU2 ZNhgkJcXUj+sPrezWeqGvYs4vvk0OJwKun9bAP2w= Content-Disposition: inline In-Reply-To: <20140403032121.GP26358@brightrain.aerifal.cx> User-Agent: Mutt/1.5.22 (2013-10-16) Xref: news.gmane.org gmane.linux.lib.musl.general:4775 Archived-At: 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 > > 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 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/