I’m trying to build anything on the Raspberry Pi and I’ve hit a roadblock.
I have a windows wsl Debian install and have a process that goes from a clean install to building the console app CMake demo.
`# update the installer index
sudo apt update
# install clang
sudo apt install clang
# install cmake
sudo apt-get install cmake
#install git
sudo apt-get install git
# install JUCE dependencies
sudo apt install libasound2-dev libjack-jackd2-dev \
ladspa-sdk \
libcurl4-openssl-dev \
libfreetype6-dev \
libx11-dev libxcomposite-dev libxcursor-dev libxcursor-dev libxext-dev libxinerama-dev libxrandr-dev libxrender-dev \
libwebkit2gtk-4.0-dev \
libglu1-mesa-dev mesa-common-dev
# clone JUCE
git clone https://github.com/juce-framework/JUCE.git
# go to the juce folder
cd JUCE
# build juce
# Configure build with library components only
cmake -B cmake-build-install -DCMAKE_INSTALL_PREFIX=/path/to/JUCE/install
# Run the installation
cmake --build cmake-build-install --target /path/to/JUCE/install`
The path to juce install is set valid for my system
on the WSL machine this works.
On the RaspberryPi it stops at “Building Juceaide” and never moves on. I have left it for hours in case it was juist slow.
Does anyone have any idea why its locking up, or is it a Juce bug?
I’m going to keep updating this thread as I make progress so it may help others.
I was able to build the console app correctly by reverting to 7.0.1
I will now sped time going forward until I find the failure point.
For addressing stuck/hanged processes, you can always use the strace tool on Linux to debug your build - attach it to the hung process and see what signals are being generated, in case it is actually doing something - or wait to let strace show you other details for why the build process is hanging … an example of how to do this is here:
Maybe a stupid thing to point out, but git bisect will help you find the point where it broke in the fastest possible time. Not sure what you meant by “I will now sped time going forward until I find the failure point”, but if you’re going to do it by check out 7.0.2, build, test, checkout 7.0.3, build, test, etc., then bisecting will be better.
Are you trying to compile on the actual RPi? If that works at all, I would expect it to be incredibly slow. I would highly suggest crosscompiling to the Pi on a desktop system.
There’s absolutely no reason not to compile onboard, its the safest and most productive way to do an rPi build - but would I use this as a regular development flow?
No, I’d just use the fastest machine in my environment for development, and fire up builds on the rPi when things are ready to be tested. Cross-compiling is introducing a whole new level of hurt into an already complicated build environment and I would not advise it unless you have a really, really good reason to do so. This is a non-native approach that is fraught with its own frustrations.
@Freekstorm - Yes, the “Building juceaide” step is hanging, and one of the processes involved in that build step is stuck - my advice was to use the strace techniques as described, to find what process is hung, strace it, and find what system calls it is stuck in. You can do this, its not that difficult - get the rPi in the hanging state, open up another terminal, find out which of the build processes is hanging, attach to it using strace, and try to work out which system call it is stuck in - if you can provide this info, we can maybe see why its hanging.
Failing that, I have an rPi too and haven’t done a build of my own work on it in a while, I’ll give it a try later in the week in case you haven’t sorted it. I personally believe rPi to be one of the most exciting platforms for JUCE, so I’m happy to see this get sorted …
@austrianaudioJV When I started I wanted to check the toolchain, so I compiled Juce on windows, then on a wsl Debian, I moved to checking the rpi was working. Which is where it came unstuck. I’m not planning on working on the RPi for all of it, as you say, use the fastest machine, and the do checks.
I’m glad I did because failure of the basic ConsoleApp means I’m not mistakenly trying to debug my code
I spent some time doing the git bisect and this is the breaking commit data:
strace the hung process. This is the way forward. You’ll see what system call it is hanging on and this can give us clues.
Good you found the patch where the hangs started happening - but this is a big bundle of string to pull on … better to just go straight to the root of the problem and debug the hanging system call.
@anon48770766 Unfortunately, I know very little about Linux. I looked at the strace docs and that was a lot to take in. I really dont know where to go from here.
I know that V7.0.5 works on Windows and RPi, so I will probably just stick with that until I have some more Linux experience.
I have the same issue. I saw on htop that it takes more than 500 MB of ram to compile, so it goes into swap and that makes the whole system hang.
It is said it helps doing things that CMake cannot. Could I ask exactly what are the inputs and outputs of juceaide? Can we have some way to detect branch and bound type stuff that can reduce the calculation needed? Thank you.
Are you building with makefiles, or with Ninja? If you’re using Ninja, it will normally scale the number of concurrent builds with the number of cores, which may exhaust available memory.
As a workaround, you could try building with makefiles (sequential by default). Alternatively, if you want to use Ninja, in extras/Build/juceaide/CMakeLists.txt line 136 you could try adding --parallel 1, i.e.
Hi,
Thank you for the help. I went a bit deeper and tried to find why juceaide is used. I wanted to use the juce_add_console_app cmake recipe, and found that juceaide is only used in one of the sub-recipes for building some mac related stuff (_juce_add_xcode_entitlements), which was not my use case. So i commented out that recipe and was able to build without juceaide.
PS : more context: I am using Cmake build system on linux, with JUCE_MODULES_ONLY, which prevents juce_add_console_app from being defined, so i copied the necessary recipes, of which the above is the only one that requires juceaide
Since you’ve confirmed that it is a swap issue, you can also increase the swap size like so:
The caveat is that doing this may hammer your SD card over the long term, so moving at least your repo off the SD card filesystem and onto something connected over USB3 or PCIe is the way to go.
Also these days, another option is to get a beefy 8GB or 16GB RPi5 that can be your compiler for your lesser-powered Raspberry Pi(s). If cross-compiling is too much of a pain to set up, the positive of this approach is that you can test your GPIO stuff, custom (touch)screen stuff, all from the same platform you’re deploying to.
It’s the same reason I like to debug Android and iOS on a physical device often instead of use the emulator… emulator isn’t always as useful depending on what you’re testing!
Speaking of this, I just ran into a similar issue where my RPi5 was locking up during compilation of BinaryData, and I just found another solution which seems to fix it:
