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.
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.
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 -
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?
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 …
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
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
I have succesfully cross compiled my juce project for the rpi4 using crosstool-ng to generate a toolchain, and then using cmake to compile. You only have to build the toolchain once then whenver you want to cross compile you just point cmake to the toolchain file and it will use the cross compiler to compile from x86-64 to ARM. Using crosstool-ng also allows you to optimize the toolchain a bit depending on what Pi you have. There are a lot of options you can enable.
It also has a pretty small footprint. I was able to put the toolchain in a docker container and cross compile using github actions very easily.
Since it was so much trouble to get this working I wrote a little article about it here
Hey @denvercoder9 , thanks a lot for that article.
Im getting all kinds of problems with rsync with permissions (fixed it in /etc/sudoers) and with error code 40 ( too many levels of syslinks )
Do you know of some magic to make this work ?
I replaced the neccesary info and Im triying to xcompile for rpi3 and 4
