Date: Wed, 16 Apr 2014 10:24:14 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: Glen Barber <gjb@FreeBSD.org>, freebsd-arm@FreeBSD.org Subject: Re: What happened to 11-Current ARM Message-ID: <40D86548-EA3E-49D5-B95B-97BAC7AFB716@bsdimp.com> In-Reply-To: <1397654459.1124.136.camel@revolution.hippie.lan> References: <534D99CB.40607@gmail.com> <20140415204516.GF33565@glenbarber.us> <1397595942.1124.125.camel@revolution.hippie.lan> <20140415211341.GG33565@glenbarber.us> <DE749EF3-4916-4A66-9FE7-24DC7F5784E5@bsdimp.com> <20140415221934.GH33565@glenbarber.us> <20140415232211.GI33565@glenbarber.us> <20140416015925.GM33565@glenbarber.us> <D911B5E9-BE2C-4C07-94AB-727E2EAE6711@FreeBSD.org> <1397654459.1124.136.camel@revolution.hippie.lan>
index | next in thread | previous in thread | raw e-mail
On Apr 16, 2014, at 7:20 AM, Ian Lepore <ian@FreeBSD.org> wrote: > On Wed, 2014-04-16 at 09:01 +0100, Mark R V Murray wrote: >> On 16 Apr 2014, at 02:59, Glen Barber <gjb@FreeBSD.org> wrote: >> >>> On Tue, Apr 15, 2014 at 07:22:11PM -0400, Glen Barber wrote: >>>> On Tue, Apr 15, 2014 at 06:19:34PM -0400, Glen Barber wrote: >>>>> On Tue, Apr 15, 2014 at 03:39:35PM -0600, Warner Losh wrote: >>>>>> >>>>>> On Apr 15, 2014, at 3:13 PM, Glen Barber <gjb@FreeBSD.org> wrote: >>>>>> >>>>>>> On Tue, Apr 15, 2014 at 03:05:42PM -0600, Ian Lepore wrote: >>>>>>>> On Tue, 2014-04-15 at 16:45 -0400, Glen Barber wrote: >>>>>>>>> On Tue, Apr 15, 2014 at 01:42:51PM -0700, Jungle Boogie wrote: >>>>>>>>>> Hello All, >>>>>>>>>> >>>>>>>>>> Weekly I check on what's been updated for ARM on 11-CURRENT and this week, >>>>>>>>>> there's only one image and its for the zedboard. >>>>>>>>>> >>>>>>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0 >>>>>>>>>> >>>>>>>>>> Is this expected from now on? >>>>>>>>> >>>>>>>>> The builds failed for RPI-B, BEAGLEBONE, and WANDBOARD-QUAD. >>>>>>>>> >>>>>>>>> Glen >>>>>>>>> >>>>>>>> >>>>>>>> Failed how? Is there a build log to look at? Do emails go out on >>>>>>>> failure, like with tinderbox, and I'm not on the right list? >>>>>>>> >>>>>>> >>>>>>> No, these build logs are not mailed. >>>>>>> >>>>>>> armv6-freebsd-gcc: not found >>>>>>> >>>>>>> I don't know what changed, or when, but have not had time to look into >>>>>>> this. >>>>>> >>>>>> You likely need to add WITHOUT_CLANG=t WITH_GCC=t to the crochet build of xdev. >>>>>> >>>>> >>>>> This is actually the default in this case. >>>>> >>>>> The build environment has armv6-freebsd-cc and armv6-freebsd11.0-cc, >>>>> but no armv6-freebsd-gcc. >>>>> >>>> >>>> It seems WITHOUT_CLANG_IS_CC=1 is also needed. >>>> >>>> Sigh... >>>> >>> >>> Also, this is "cute"... >>> >>> armv6-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail >>> /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:9138 >>> gmake: *** [u-boot] Segmentation fault (core dumped) >>> gmake: *** Deleting file `u-boot' >>> >>> If there is going to be any expectation for armv6 being a tier-1 >>> architecture, well, it just isn't going to work with the current state >>> of things. >> >> And I’m getting >> >> rm -f .depend >> mkdep -f .depend -a -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include … >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> cc: error trying to exec 'cc1plus': execvp: No such file or directory >> : >> : >> >> >> Full log available on request, but I have some other nasty hacks in place (that have relevance mainly during the full build; I null-mount src/ and ports/ instead of checking them out). >> >> M > > I find that to switch compilers I now need all of this in make.conf: > > WITHOUT_CLANG=yes > WITHOUT_CLANG_IS_CC=yes > WITH_GCC=yes > WITH_GNUCXX=yes > > It used to be sufficient to say WITHOUT_CLANG_IS_CC, but now you need to > throw multiple switches at once to get the old behavior. I for one think CLANG_IS_CC is a crock of crap. I was told several BSDcans ago that it was a temporary thing, but its staying power is distressing. I’d rather see the following: DEFAULT_COMPILER {clang,gcc} when set, causes a symlink from cc to this value. In an ideal world this could also be something like /usr/local/bin/gcc48 too. BOOTSTRAP_COMPILER {clang,gcc,external} which compiler is build to bootstrap the system. If unset, it defaults to the DEFAULT_COMPILER You’d set MK_{CLANG,GCC,GNUCXX} based on these values before processing WITH/WITHOUT_FOO (which would also allow someone to override what’s built if the logic was wrong. Warnerhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40D86548-EA3E-49D5-B95B-97BAC7AFB716>