FTBFS: zedboard BSP with SMP

Jonathan Brandmeyer jonathan.brandmeyer at gmail.com
Wed May 6 22:38:33 UTC 2015

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?


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-0002.html>

More information about the users mailing list