FTBFS: zedboard BSP with SMP

[Jonathan Brandmeyer]

Resolved.  The link was picking up an old copy of librtemscpu.a from the
--prefix when rebuilding.

What is the cleanest way of blowing away an old compiled BSP when
rebuilding it to avoid this in the future, while retaining the toolchain in
the chosen prefix?

Thanks,
Jonathan


On Wed, May 6, 2015 at 12:02 PM, Jonathan Brandmeyer <
jonathan.brandmeyer at gmail.com> wrote:

> Today's Git master does not currently build with SMP support enabled.
>
> Toolchain is the latest arm/rtems-4.11
> Configured from a separate build directory with:
>
> $../rtems-git/configure --target=arm-rtems4.11 --enable-smp --enable-posix
> --disable-networking --enable-cxx --enable-rtemsbsp="xilinx_zynq_zedboard"
> --enable-tests=samples --prefix=/home/jonathan/Programs/rtems_4_11
>
> The sample tests build fails with undefined references to
> init.o:(.rodata+0x10c): undefined reference to
> `_Scheduler_default_Ask_for_help'
> init.o:(.rodata+0x12c): undefined reference to
> `_Scheduler_default_Get_affinity'
> init.o:(.rodata+0x130): undefined reference to
> `_Scheduler_default_Set_affinity'
>
> Also cache_manager.o from within libbsp has undefined references to:
> _SMP_Multicast_action
> _SMP_Start_multitasking_on_secondary_processor
>
>
> The build does succeed as of commit
> 40d24d54ab59fdb2e4133128bf184ec8935f3545
>
>
> -Jonathan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150506/3607a407/attachment-0001.html>