ARM build failing

Chris Johns chrisj at rtems.org
Mon Apr 9 05:38:33 UTC 2018


On 09/04/2018 15:29, Sebastian Huber wrote:
> On 09/04/18 07:20, Chris Johns wrote:
>> On 09/04/2018 15:05, Sebastian Huber wrote:
>>> On 09/04/18 01:06, Chris Johns wrote:
>>>> I am testing testsuite Makefile.am changes and the following configure:
>>>>
>>>> /opt/work/chris/rtems/kernel/rtems.git/configure
>>>> --prefix=/opt/work/rtems/bsps/5
>>>> --target=arm-rtems5 --enable-posix --enable-networking --enable-smp
>>>> --enable-tests --enable-maintainer-mode
>>>>
>>>> fails with:
>>>>
>>>> gmake[5]: Entering directory
>>>> '/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c/atsamv/cpukit/score'
>>> The --enable-smp doesn't work with this BSP.
>>>
>> Seems a brutal way to let a user know?
>>
>> Considering this is a little it means --enable-smp and --enable-multiprocessing
>> is broken when the BSP wildcard is used. Should we require a BSP or list of BSPs
>> be provided to configure? It would avoid this issue?
> 
> I think for the --enable-multiprocessing we already have something like this:
> 
> c/src/aclocal/check-multiprocessing.m4
> 

Yes.

> I am not sure if we should omit BSPs which cannot cope with a --enable-* option.
> If you want to build all BSPs you want to build all BSPs?
> 

I think it would too hard at this point in time to probe and create a list of
those BSPs that support the options. I am thinking if you use --enable-smp or
--enable-multiprocessing you must provide a list of BSPs so the wildcard or all
default cannot be used. If a user supplies a BSP that is not support that is a
different issue and the need to handle that better for SMP would be nice.

Chris



More information about the devel mailing list