From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Tue, 09 Sep 2014 23:48:31 +0200 Subject: [U-Boot] [PATCH v2 7/8] Makefile: default to cc for host compiler In-Reply-To: References: <1406750096-7281-1-git-send-email-jeroen@myspectrum.nl> <1406750096-7281-8-git-send-email-jeroen@myspectrum.nl> <20140731190122.D4F3.AA925319@jp.panasonic.com> <540F3A34.9000404@myspectrum.nl> Message-ID: <540F75AF.6060503@myspectrum.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 09-09-14 21:59, Albert ARIBAUD wrote: > Hi Jeroen, > > On Tue, 09 Sep 2014 19:34:44 +0200, Jeroen Hofstee > wrote: > >> Hello Albert, >> >> On 09-09-14 16:31, Albert ARIBAUD wrote: >>> On Thu, 31 Jul 2014 19:01:22 +0900, Masahiro Yamada >>> wrote: >>> >>>>> HOSTCXX = g++ >>>>> HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer >>>> For consistency, >>>> >>>> HOSTCXX = c++ >>>> >>>> ? >>> So, Jeroen, what is your pick ? Will you send a v3 7/8, or are you >>> sticking with g++? >>> >>> (or if everyone agrees, I could to the change to v2 7/8 when applying >>> it, and add a comment about it in the commit message.) >> I did check Masahiro's statement that cpp is actually used in u-boot >> and it is; make xconfig uses it, if I recall correctly. And as Masahiro >> suggested I sent it to linux-kbuild mailinglist, but I am in the impression >> it never arrived, perhaps I need to be subscribed or something... >> >> Anyway, Masahiro's suggestion is sound and I am fine you changing >> it while applying. I tested it on FreeBSD, Xubuntu and Debian. > I've tried building rpi_b as per the README, but I keep getting > > /usr/bin/as: unrecognized option '-mfloat-abi=soft' > clang: error: assembler command failed with exit code 1 (use -v > to see invocation) > > Shouldn't rpi_b build properly since it is the one given as an example > for Debian-based building? > > As discussed with Albert there seems to be some Debian / Ubuntu specific changes to the package causing trouble. Checking out the llvm 3.5 branch works fine, using the package fails with above mentioned error. No idea why at the moment, patches are fine... Regards, Jeroen