ARM Getting Started Assistance: Beagleboard, Zedboard, or STM32F4Discovery?

[Jonathan Brandmeyer]

On Sun, Feb 1, 2015 at 4:53 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>
>
> On February 1, 2015 4:40:45 PM MST, Ben Gras <beng at shrike-systems.com> wrote:
>>Dear all,
>>
>>I took a quick look at why the beagle bsp fails to link. It seems
>>there is a multilib interaction I don't really understand that is
>>causing the symbol to be missing. (The symbol appears in some library
>>arch variants and not in others.) I'm not too familiar with how that
>>works so I can't find a clean solution right now.
>
> Building multilib is rather useless to most people. It builds the cpukit for every arm CPU variant GCC knows. In this case, the error is in a variant we don't have a BSP for. You only need one of the variants. More below.
>
> Build rtems for a single BSP and drop the multilib option. For some BSPs, you might see an issue linking a dynamic loading test. I saw  it on the Pi last week but the other test ran.

I must have misunderstood something fundamental about how RTEMS builds
then.  I used multilibs this first round specifically because several
different architecture variants were being requested.  ARM-V7M,
ARM-v7ME, and ARM-V7A are all quite different from each other.  I had
rather assumed that RTEMS generic code would get compiled for each
architecture variant, and then the BSP would build for only its own
variant with the right flags to pick up the correct subarch.

Rebuilding only one BSP per build directory and explicitly
--disable-multilib works around the build failures for beagleboard and
stm32 testsuite programs.  When building in this mode, does each BSP
need a different --prefix?  Or can they all be installed to the same
prefix?

Thanks,
Jonathan