Juceaide never completes on Raspberry Pi4

Linux
1

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?

2

I also hit this issue recently. I put it down to the board I was using, a RPi zero. But the same thing happened for me, it just hung.

FWIW, I have built JUCE based software on RPi’s before without any issue. But that was before JUCE’s CMake support.

3

Thanks for the reply.
I might try going back in the repo to see if any earlier version of 7 work.

4

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.

5

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:

https://www.joshmcguigan.com/blog/troubleshooting-stuck-process/

6

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.

7

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.

8

Thanks for the replies.

@ austrianaudioJV
The step that break is the “Building juceaide” step, so Im not sure how connecting the debugger would help.

@ asimilon
Ill check out git bisect, thanks

For now i have a script that runs and moves to the next revision, then builds the stack.
So its fairly easy to step though them.

@ benvining
I have an RPi, it takes around 4 minutes (when its working) to go from juce install to consoleapp build, so not too long

9

I got so frustrated trying to get the cross compiling working I ended up buying myself RPi4 and building natively!

10

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 …

11

@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 :slight_smile:

I spent some time doing the git bisect and this is the breaking commit data:

richard@raspberrypi:~/projects/JUCE $ git bisect good
9d1a6a3b28f90c055905114d63a2edec932f472f is the first bad commit
commit 9d1a6a3b28f90c055905114d63a2edec932f472f
Author: reuk <reuk@users.noreply.github.com>
Date:   Mon Mar 20 20:55:26 2023 +0000

    ContentSharer: Update interface to return safer ScopedMessageBox instances

 BREAKING-CHANGES.txt                               |  26 +
 examples/DemoRunner/CMakeLists.txt                 |   1 +
 examples/GUI/CameraDemo.h                          |  22 +-
 examples/GUI/DialogsDemo.h                         |   6 +-
 extras/AudioPluginHost/CMakeLists.txt              |   1 +
 .../ProjectSaving/jucer_ProjectExport_Android.h    |   4 +
 .../juce_core/native/juce_android_JNIHelpers.cpp   |  48 +-
 modules/juce_core/native/juce_android_JNIHelpers.h |  46 +-
 .../detail/juce_ScopedContentSharerImpl.h          |  98 +++
 .../detail/juce_ScopedContentSharerInterface.h     | 211 +++++
 .../detail/juce_ScopedMessageBoxImpl.h             |  33 +-
 .../filebrowser/juce_ContentSharer.cpp             | 252 +-----
 .../filebrowser/juce_ContentSharer.h               | 106 +--
 modules/juce_gui_basics/juce_gui_basics.cpp        |   3 +
 .../native/javaopt/app/com/rmsl/juce/Receiver.java |  42 +
 .../native/juce_android_ContentSharer.cpp          | 921 +++++++++++----------
 .../native/juce_ios_ContentSharer.cpp              | 189 ++---
 .../juce_gui_basics/native/juce_ios_FileChooser.mm |  62 +-
 .../native/juce_ios_NativeModalWrapperComponent.h  | 132 +++
 .../juce_gui_basics/windows/juce_AlertWindow.cpp   |   4 +-
 .../windows/juce_NativeMessageBox.cpp              |   4 +-
 .../windows/juce_ScopedMessageBox.h                |   6 +-
 22 files changed, 1244 insertions(+), 973 deletions(-)
 create mode 100644 modules/juce_gui_basics/detail/juce_ScopedContentSharerImpl.h
 create mode 100644 modules/juce_gui_basics/detail/juce_ScopedContentSharerInterface.h
 create mode 100644 modules/juce_gui_basics/native/javaopt/app/com/rmsl/juce/Receiver.java
 create mode 100644 modules/juce_gui_basics/native/juce_ios_NativeModalWrapperComponent.h

Now to try to find the exact cause of the failure.

12

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.

13

@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.

Not the end of the world :slight_smile:

1 Like