Crosscompile to ARM (Raspberry)


#1

Hey folks, I already succesfuly compiled standalone JUCE projects and demos in the Raspberry 3 but it’s painfully slow compared with building them in my computer, so my idea was to cross-compile them for an ARM target (from Ubuntu 18.04) and send the built app over scp.

The thing is I’ve tried installing all dependencies, ARM gcc and relatives and so on, having read almost all ARM posts here and on web, but I seem to hit the same wall: the -march=armv8-a+crc (neither any arm) target isn’t detected but only x86 targets appear.

Has anyone here had succes with that?


#2

Hi, I am also using the RPI3.

The way I cross-compile is by using buildroot (builds an entire Linux os).
Here is a link to Erpiam, which is similar: https://github.com/gbevin/erpiam
I just copy the executable via ssh to the RPI after building.

I don’t know whether this is the best way, but it works well for me.

I saw your post because I am now also trying to figure out how to use ARM NEON vectorization for the Juce with gcc. Could not get it to work yet (I use CMake), any hints appreciated.


#3

I’m also haven’t seen yet a nice crosscompile workflow.
With QT there are some workflows but again there’s nothing working out-of-the-box.
This looks interesting -


#4

Thanks for both answers, sadly we are a bit alone on this since most people here uses JUCE for plugins standalone x86 apps.

@ivofx I still haven’t got to the NEON point (I’m on the i2c part + polling threads for external knobs) but this is something I will end up doing soon, so anything we can help between the few of us that are on the embedded stuff will be great.
I didn’t exactly get the executable part tho. Do you mean you make a build in buildroot everytime you recompile your code? Doesn’t it take even longer than just compiling it in the Projucer inside the RPI?


#5

Hey @johngalt91.

Whenever I enabled #define JUCE_USE_SIMD 1 I would get a compilation error. Updating from Juce 5.3 to the latest I resolved my problem after all. I believe JUCE_USE_ARM_NEON is then activated automatically, but it probably does not hurt to set it anyway.

I am not rebuilding the entire OS every time if that is what you are concerned about, it only needs to be done once (there is a handy tool named “ccache” which can save a lot of time in case you do rebuild the OS. The first time took several hours).
You set up a buildroot “package” and tell it where your CMake/Makefile is, here are the docs:
https://buildroot.org/downloads/manual/manual.html#_infrastructure_for_cmake_based_packages

To build from a local source instead of fetching from the web, add something like this in your mk file:

PIQUENCER_SITE = /music/juce/piquencer
PIQUENCER_SITE_METHOD = local

I recompile my app in buildroot after every change, the compilation time is not very long and certainly much faster than compiling on the RPI itself. One big drawback however is that buildroot does not allow building gdb for the RPI, instead it is suggested to do remote debugging from a PC.

Does the Projucer-App support building in Linux? The last time I checked it did not …

For the ARM flags I referred to this article https://gist.github.com/fm4dd/c663217935dc17f0fc73c9c81b0aa845

So these gcc flags do compile for me on RPI 3 B (I tested in raspbian gcc as well as buildroot) like suggested by the article
-mcpu=cortex-a53 -mfpu=neon-fp-armv8 -mneon-for-64bits -mfloat-abi=hard -mtune=cortex-a53


#6

Many thanks, I just love you. Such a great response that will definitely save me tons of times.

If you mean building the Projucer-app itself in Linux yes you definitely can. You will need this packages in case you wanna try it in the RPi3 (just run the command):
sudo apt-get install clang freeglut3-dev g++ libasound2-dev libcurl4-openssl-dev libfreetype6-dev libjack-jackd2-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev libxrandr-dev mesa-common-dev webkit2gtk-4.0 ladspa-sdk

Then:
cd /*yourRouteToJUCEFolder*/JUCE/extras/Projucer/Builds/LinuxMakefile
make