What happened to 11-Current ARM

[Warner Losh]

On Apr 16, 2014, at 7:20 AM, Ian Lepore <ian at 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 at 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 at 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.

Warner