Guidance building for Bela platform

Usage Questions
23

Ok, I can confirm that I can get stuff to build and load by full cross compiling. I see from your thread above that there’s a new a Bela image with an updated CMake, so I’ll give that a shot and introduce myself to the world of distcc later in the week. If trying to build is just pissing you off and wasting time, I can just sling you the binaries I have for now.

Some caveats: the FluidTransient(Slice) objects and their Buffer processing cousins won’t currently build for ARM. Overall, too, performance is a bit shitty: I’m getting lots of underruns from the audio decomposition objects like FluidSines and FluidHPSS (which are the simplest to test in a Bela IDE context). My best guess is that it’s because Bela’s vector size is 16 samples, and something in our code is dealing poorly with that: I’ll confirm by profiling on my machine with smaller vector sizes and see what I see.

The cross compiling dance isn’t too awful (on recent macOS)

  • You need arm-linux-gnueabihf-binutils and llvm installed from homebrew
  • To get a viable sysroot, I followed the lead of this post and rsync’d a bunch of folders over from the Bela
see list of folders 
/usr/lib/arm-linux-gnueabihf 
/usr/lib/gcc/arm-linux-gnueabihf 
/usr/include 
/lib/arm-linux-gnueabihf
  • Then I mashed the keyboard based on haphazard googling and came up with a CMake toolchain file (which could definitely be more portable, and probably more correct in some ways)
see arm-linux-gnueabihf.cmake 
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(triple arm-linux-gnueabihf)
set(gcc_toolchain /usr/local/Cellar/arm-linux-gnueabihf-binutils)
set(bela-sysroot /Users/owen/bela-sysroot)    
set(CMAKE_SYSROOT ${bela-sysroot})  
set(CMAKE_C_COMPILER clang)
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_CXX_COMPILER_TARGET ${triple})
set(flags "-I/usr/local/opt/llvm/include -isystem=${bela-sysroot}/usr/include/c++/6.3.0 -isystem=${bela-sysroot}/usr/include/carm-linux-gnueabihf -B${bela-sysroot}/usr/lib/gcc/arm-linux-gnueabihf/6.3.0 -march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon")
set(CMAKE_C_FLAGS ${flags} CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS ${flags} CACHE STRING "" FORCE)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

Then you add --toolchain <path to arm-linux-gneabihf.cmake> to your CMake invocation. If it compiles but won’t link, then that’s generally a sign that it hasn’t got the message about the different compiler / sysroot. Because a lot of these are cache variables, srubbing the build folder or CMakeCache.txt and reconfiguring from clean can make debugging much less surprising. I updated my $PATH to have the llvm bin folder at the start, which would be nice to avoid, but isn’t the end of the world.

After that, it seems happy enough (modulo the caveats above: the transient objects should be disabled by deleting or renaming their CMakeLists files).

1 Like