compile errors on Raspberry Pi 3

[madamdata]

Hi,
I recently followed the instructions on the wiki : [https://supercollider.github.io/development/building-raspberrypi.html]
Under the "building with IDE" heading.
When I tried to compile SC, I got this error at 32% :

[ 31%] Building CXX object editors/sc-ide/CMakeFiles/SuperCollider.dir/widgets/main_window.cpp.o
[ 31%] Building CXX object editors/sc-ide/CMakeFiles/SuperCollider.dir/widgets/multi_editor.cpp.o
[ 32%] Building CXX object editors/sc-ide/CMakeFiles/SuperCollider.dir/widgets/post_window.cpp.o
g++-4.8: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
editors/sc-ide/CMakeFiles/SuperCollider.dir/build.make:788: recipe for target 'editors/sc-ide/CMakeFiles/SuperCollider.dir/widgets/lookup_dialog.cpp.o' failed
make[2]: *** [editors/sc-ide/CMakeFiles/SuperCollider.dir/widgets/lookup_dialog.cpp.o] Error 4
make[2]: *** Waiting for unfinished jobs....

I'm using a raspberry pi 3 with Raspbian installed from NOOBS 1.9.0, ran all the update, upgrade and dependency installation steps with no issues. GCC version (gcc -v) is 4.9.2, but I also ran the steps to ensure 4.8.4 was used - I saw this line:
The C compiler identification is GNU 4.8.4
I had checked out the 3.7 branch when I got the above error, but I also get an error in the same step using the Master branch.

uname -a gives me:
Linux raspberrypi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

cat /etc/os-release gives:
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian

etc.

Any help would be appreciated!

[redFrik]

a wild guess… running out of ram? lower your gpu memory split to 16 (under sudo raspi-config -> advanced), reboot and try make -j4 again.
_f

23 apr 2016 kl. 00:56 skrev thumbthumb notifications@github.com:

Hi,
I recently followed the instructions on the wiki : [https://supercollider.github.io/development/building-raspberrypi.html]
Under the "building with IDE" heading.
When I tried to compile SC, I got this error at 32% :

g++-4.8: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
editors/sc-ide/CMakeFiles/SuperCollider.dir/build.make:788: recipe for target 'editors/sc-ide/CMakeFiles/SuperCollider.dir/widgets/lookup_dialog.cpp.o' failed
make[2]: *** [editors/sc-ide/CMakeFiles/SuperCollider.dir/widgets/lookup_dialog.cpp.o] Error 4
make[2]: *** Waiting for unfinished jobs....

I'm using a raspberry pi 3 with Raspbian installed from NOOBS 1.9.0, ran all the update, upgrade and dependency installation steps with no issues. GCC version (gcc -v) is 4.9.2, but I also ran the steps to ensure 4.8.4 was used - I saw this line:
The C compiler identification is GNU 4.8.4
I had checked out the 3.7 branch when I got the above error, but I also get an error in the same step using the Master branch.

uname -a gives me:
Linux raspberrypi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

cat /etc/os-release gives:
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian

etc.

Any help would be appreciated!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

#|
fredrikolofsson.com musicalfieldsforever.com
|#

[madamdata]

I tried what you suggested: got a different bug.

[ 48%] Building CXX object editors/sc-ide/CMakeFiles/SuperCollider.dir///QtCollider/layouts/moc_stack_layout.cpp.o
[ 48%] Building CXX object editors/sc-ide/CMakeFiles/SuperCollider.dir/qrc_resources.cpp.o
Linking CXX executable scide
[ 48%] Built target SuperCollider
Makefile:147: recipe for target 'all' failed
make: *** [all] Error 2

[bagong]

I'll try to build this weekend and see what I get. Another wild guess: Your build errors seem all to be in the QtCollider/IDE-part, so Qt-related. This, I guess, is the least tested part of the build. In the past - using RP1, where it was hopeless to run the IDE - people used to switch off Qt with -DSC_QT=OFF and use sc in headless mode (control it either from a remote or use the readline-interface), and actually use the entire RP in command line mode only (or use Sonic Pi ;)), which btw makes getting jackd to work a bit of a hassle.

• So what's the Qt-version (see in the package manager, or try qmake -v)?
• It might be worth trying with the 4.9 compiler (with -fno-strict-aliasing, or in an early build iteration just build in debug mode (-DCMAKE_BUILD_TYPE=Debug)), as the Qt-dev files on the system kind of expect gcc 4.9...
• And maybe you want to try a build with -DSC_QT=OFF just to see how far you get with the build?

These are just steps to gradually narrow down into the actual problem, likely quite a few builds will be required to get there. Ideally you can provide a bit of patience ;)

[bagong]

I got it to build on an RP2b with Raspbian. I am not happy yet, get "JackDriver: exception in real time: alloc failed, increase server's memory allocation (...)", and simply increasing memSize doesn't help. But at least on the RP2b the build errors can be avoided with the current packages (Qt 5.3.2)

What I did, what seems not to be mentioned in the build instructions, was to make sure Qt5 was used by setting the environment var QT_SELECT:

export QT_SELECT=5

Not sure what would have happened without that.

And I noticed that closing X and building from the cli is significantly faster.

I did use a slightly different approach as in the build instructions. Kept the default gcc 4.9.2, just switched supernova off, and used -fno-strict-aliasing in addition to the documented c/c++-flags:

cmake -DSUPERNOVA=OFF -DCMAKE_C_FLAGS="-mtune=cortex-a7 -mfloat-abi=hard -mfpu=neon -funsafe-math-optimizations -fno-strict-aliasing" -DCMAKE_CXX_FLAGS="-mtune=cortex-a7 -mfloat-abi=hard -mfpu=neon -funsafe-math-optimizations -fno-strict-aliasing" ..

I'll try to find out what's wrong with the server/jackd. If somebody has an idea... Just reinstalling jackd didn't help. Realtime priority for the audio group is set to 95, memlock unlimited, user pi a member of the audio group. Do I still need to compile jack or should the distributed version be fine?

Will get a RP3 in 3 days, will try again then ;)

[redFrik]

those instructions were written before there was a rpi3 and before your (great) -fno-strict-aliasing discovery.
but thanks for good info. i’ll try compiling on rpi3 when i get back home monday and will most likely revisit the build-instructions with your suggestions.

that jack error sounds familiar and is probably an easy one to fix. just can’t remember exactly how right now.

try:
export DISPLAY=:0.0
export dbus-launch | grep ADDRESS
export dbus-launch | grep PID
jackd -P95 -dalsa -dhw:1 -p1024 -n3 -s -r 44100 &

or
sudo apt-get install screen
dbus-launch screen
jackd -P95 -dalsa -dhw:1 -p1024 -n3 -s -r 44100 &

the distributed jackd _will work, but it’s messy to get going. fiddly dbus issues that you’ll need to work around like above. often easier to just build it from git without dbus.
_f

24 apr 2016 kl. 02:12 skrev Rainer Schütz notifications@github.com:

I got it to build on an RP2b with Raspbian. I am not happy yet, get "JackDriver: exception in real time: alloc failed, increase server's memory allocation (...)", and simply increasing memSize doesn't help. But at least on the RP2b the build errors can be avoided with the current packages (Qt 5.3.2)

What I did, what seems not to be mentioned in the build instructions, was to make sure Qt5 was used by setting the environment var QT_SELECT:

export QT_SELECT=5

Not sure what would have happened without that.

And I noticed that closing X and building from the cli is significantly faster.

I did use a slightly different approach as in the build instructions. Kept the default gcc 4.9.2, just switched supernova off, and used -fno-strict-aliasing in addition to the documented c/c++-flags:

cmake -DSUPERNOVA=OFF -DCMAKE_C_FLAGS="-mtune=cortex-a7 -mfloat-abi=hard -mfpu=neon -funsafe-math-optimizations -fno-strict-aliasing" -DCMAKE_CXX_FLAGS="-mtune=cortex-a7 -mfloat-abi=hard -mfpu=neon -funsafe-math-optimizations -fno-strict-aliasing" ..

I'll try to find out what's wrong with the server/jackd. If somebody has an idea... Just reinstalling jackd didn't help. Realtime priority for the audio group is set to 95, memlock unlimited, user pi a member of the audio group. Do I still need to compile jack or should the distributed version be fine?

Will get a RP3 in 3 days, will try again then ;)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

#|
fredrikolofsson.com musicalfieldsforever.com
|#

[bagong]

@thumbthumb, while trying to build 3.7 (using the configuration I described above) I ran into very similar issues as you, sometimes even at the same build-stage as you did. I was lucky to get a more explicit error message: "Virtual memory exhausted: Cannot allocate memory"
My intuition says that is what you ran into, and (remembering back the days on RP1, where that was a constant issue) the simplest (probably best temporary) fix is to increase your swap-file size. It's described here (including a warning about a risk of sc-card corruption, which is quite real, at least back in the days ;) ):

https://www.bitpi.co/2015/02/11/how-to-change-raspberry-pis-swapfile-size-on-rasbian/

With a swapfile of 2GB the build just went through, and quite fast. So currently - from a build-perspective - both 3.7 and latest master branch work (for RP2, but I'd be surprised if it didn't work on RP3). That almost makes me think the SC community should officially adopt Raspbian as a supported platform and create a travis build for it...

[bagong]

With that large swapfile even supernova builds and passes the tests (both master and 3.7.1). Using screen to run shipped jackd on the command line, and starting supernova, it dies with this swan-song sounding like Marsian lyrics to me ;):

Supernova booting
[ 190.026816] Unhandled fault: alignment exception (0x001) at 0x7ebd4134
[ 190.033443] pgd = b50e8000
[ 190.036179] [7ebd4134] *pgd=3672b831, *pte=2db5e55f, *ppte=2db5ec7e
Bus error

Would that have to be worked on on the supernova side, or jackd?

[madamdata]

I'm gonna try that today - thanks so much everyone!
stay tuned for reports
<3

On Sun, Apr 24, 2016 at 7:37 AM, Rainer Schütz notifications@github.com
wrote:

With that large swapfile even supernova builds and passes the tests (both
master and 3.7.1). Using screen to run shipped jackd on the command line,
and starting supernova, it dies with this swan-song sounding like Marsian
lyrics to me ;):

Supernova booting
[ 190.026816] Unhandled fault: alignment exception (0x001) at 0x7ebd4134
[ 190.033443] pgd = b50e8000
[ 190.036179] [7ebd4134] *pgd=3672b831, *pte=2db5e55f, *ppte=2db5ec7e
Bus error

Would that have to be worked on on the supernova side, or jackd?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1990 (comment)

[madamdata]

It worked!! Thank you!
Running 3.7.1 currently on my RPi 3 - I had to tweak some Jack server settings (Periods/buffer set to 4) in order to stop glitches but everything works now!

<3 <3 <3

[bagong]

Would you be so kind to post with which settings you built in the end? I am particularly interested in the details of what you did to get jackd working. I haven't succeeded yet on the RP2. You are running SC in X, right? How did you configure jackd? Use qjackctl?

[redFrik]

had a look at this today and got both sc current master and the sc 3.7 branch to build and make sound on a rpi3 - both with full scide support under jessie and as headless under jessie-lite. no problem whatsoever AS LONG AS you follow the wiki instructions and use gcc-4.8. (shipped jackd also works fine and qt selector flag not needed afaict.)

perhaps something with gcc 4.9 is still fishy because when i built sc with it i got similar issues as you… it compiled but then jack xruns and server lockup as soon as i start a synth.

i say we shouldn't change the wiki atm and gcc 4.8 should still be the recommended compiler.
but i updated the wiki instructions with a few notes that it also works on rpi3, a note about ram and new rpi3 benchmark results.

24 apr 2016 kl. 02:12 skrev Rainer Schütz notifications@github.com:

I got it to build on an RP2b with Raspbian. I am not happy yet, get "JackDriver: exception in real time: alloc failed, increase server's memory allocation (...)", and simply increasing memSize doesn't help. But at least on the RP2b the build errors can be avoided with the current packages (Qt 5.3.2)

What I did, what seems not to be mentioned in the build instructions, was to make sure Qt5 was used by setting the environment var QT_SELECT:

export QT_SELECT=5
Not sure what would have happened without that.

And I noticed that closing X and building from the cli is significantly faster.

I did use a slightly different approach as in the build instructions. Kept the default gcc 4.9.2, just switched supernova off, and used -fno-strict-aliasing in addition to the documented c/c++-flags:

cmake -DSUPERNOVA=OFF -DCMAKE_C_FLAGS="-mtune=cortex-a7 -mfloat-abi=hard -mfpu=neon -funsafe-math-optimizations -fno-strict-aliasing" -DCMAKE_CXX_FLAGS="-mtune=cortex-a7 -mfloat-abi=hard -mfpu=neon -funsafe-math-optimizations -fno-strict-aliasing" ..
I'll try to find out what's wrong with the server/jackd. If somebody has an idea... Just reinstalling jackd didn't help. Realtime priority for the audio group is set to 95, memlock unlimited, user pi a member of the audio group. Do I still need to compile jack or should the distributed version be fine?

Will get a RP3 in 3 days, will try again then ;)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #1990 (comment)

#|
fredrikolofsson.com musicalfieldsforever.com
|#

[bagong]

perhaps something with gcc 4.9 is still fishy because when i built sc with it i got similar issues as you… it compiled but then jack xruns and server lockup as soon as i start a synth.

Thanks for cross-checking!! That's the info I needed! ;)

[bagong]

So I can confirm that RP1 to RP3 compile fine with GCC 4.8, native jackd works if that compiler is used for SC and one works inside X. It's a pity that supernova doesn't work with jackd although it builds fine. On RPI/Qt-less build/use, building jackd without d-bus support doesn't require patches anymore, so this is actually a smooth build now.
Many roads lead to Rome. I found installing xvfb and running sclang with xvfb-run sclang in X-less mode where SC was built with Qt quite practical. Ah, and what actually work's on the Mac is accessing RPi SC via ssh with the option -X, and getting the SC GUI on the Mac. I didn't test it a lot, but fundamentally it works ;)

How about adding compiler flags to the general CMakeLists.txt, maybe something like:

if(${CMAKE_COMPILER_IS_GNUCXX} AND ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")
  message(STATUS "Adding compiler flags for armv7l (RPi 2&3)")
  foreach(flag CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
    set(${flag} "${${flag}} -mtune=cortex-a7")
    set(${flag} "${${flag}} -mfloat-abi=hard")
    set(${flag} "${${flag}} -mfpu=neon")
    set(${flag} "${${flag}} -funsafe-math-optimizations")
  endforeach()
elseif(${CMAKE_COMPILER_IS_GNUCXX} AND ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv6l")
  message(STATUS "Adding compiler flags for armv6l (RPi 1b)")
  foreach(flag CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
    set(${flag} "${${flag}} -march=armv6")
    set(${flag} "${${flag}} -mtune=arm1176jzf-s")
    set(${flag} "${${flag}} -mfloat-abi=hard")
    set(${flag} "${${flag}} -mfpu=vfp")
  endforeach()
endif()

Also one could add a few sentences to the Linux Readme, maybe @redFrik's required packages list (for simple copy paste) and a link to your github-page for details...

Also: in master model.sc has already been moved out of the GUI folders. What about going a step further and moving the two GUI (common and JITlib) folders into the scide_scqt folder. That would be a simple way to avoid those startup errors in headless mode? And as we are past 3.7 now, we could remove the Documents related stuff from deprecated?

A small detail: I think by default SC doesn't use a system installed boost anymore, so adding libboost-dev to the list of packages doesn't do anything (correct me if I'm wrong)

With those changes, I think what only remains to be done for a successfully build are RPi-specific things like swapfile and the sad requirement to remove Sonic Pi. Adding a test build to travis shouldn't be too difficult...

[redFrik]

really good suggestions imo. i’m all for them.
i’ll check that libboost-dev package and your cool -X trick and report back (in a few days).
thanks.

30 apr 2016 kl. 11:06 skrev Rainer Schütz notifications@github.com:

So I can confirm that RP1 to RP3 compile fine with GCC 4.8, native jackd works if that compiler is used for SC and one works inside X. It's a pity that supernova doesn't work with jackd although it builds fine. On RPI/Qt-less build/use, building jackd without d-bus support doesn't require patches anymore, so this is actually a smooth build now.
Many roads lead to Rome. I found installing xvfb and running sclang with xvfb-run sclang in X-less mode where SC was built with Qt quite practical. Ah, and what actually work's on the Mac is accessing RPi SC via ssh with the option -X, and getting the SC GUI on the Mac. I didn't test it a lot, but fundamentally it works ;)

How about adding compiler flags to the general CMakeLists.txt, maybe something like:

if(${CMAKE_COMPILER_IS_GNUCXX} AND ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")
message(STATUS "Adding compiler flags for armv7l (RPi 2&3)")
foreach(flag CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
set(${flag} "${${flag}} -mtune=cortex-a7")
set(${flag} "${${flag}} -mfloat-abi=hard")
set(${flag} "${${flag}} -mfpu=neon")
set(${flag} "${${flag}} -funsafe-math-optimizations")
endforeach()
elseif(${CMAKE_COMPILER_IS_GNUCXX} AND ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv6l")
message(STATUS "Adding compiler flags for armv6l (RPi 1b)")
foreach(flag CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
set(${flag} "${${flag}} -march=armv6")
set(${flag} "${${flag}} -mtune=arm1176jzf-s")
set(${flag} "${${flag}} -mfloat-abi=hard")
set(${flag} "${${flag}} -mfpu=vfp")
endforeach()
endif()

Also one could add a few sentences to the Linux Readme, maybe @redFrik's required packages list (for simple copy paste) and a link to your github-page for details...

Also: in master model.sc has already been moved out of the GUI folders. What about going a step further and moving the two GUI (common and JITlib) folders into the scide_scqt folder. That would be a simple way to avoid those startup errors in headless mode? And as we are past 3.7 now, we could remove the Documents related stuff from deprecated?

A small detail: I think by default SC doesn't use a system installed boost anymore, so adding libboost-dev to the list of packages doesn't do anything (correct me if I'm wrong)

With those changes, I think what only remains to be done for a successfully build are RPi-specific things like swapfile and the sad requirement to remove Sonic Pi. Adding a test build to travis shouldn't be too difficult...

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

#|
fredrikolofsson.com musicalfieldsforever.com
|#

[redFrik]

thanks @bagong, i could confirm that libboost-dev isn't needed and removed it from the wiki instructions. i tested both master and 3.7.
(couldn't get the ssh -X trick to work, but i didn't spend much time on it.)

[bagong]

(couldn't get the ssh -X trick to work, but i didn't spend much time on it.)

Well, it's secondary, isn't it. Ah, probably you have to install XQuartz! ;)

http://www.xquartz.org/

I'd like to see that stuff mentioned above in master. What do you think?

• add the compiler flags (is the system detection above correct, or might that cover systems, that don't fit the variables)
• add a few sentences to Linux readme
• move the two GUI folders from common and JITLib to scide_scqt and the documents stuff out of the deprecated file. It's meaningless on Qt-only systems anyways I think, isn't it...

What do you think, worth a PR?

[redFrik]

sure, it would be great to have in master. i don't dare to touch the cmake file but i could contribute something to the readme.
although for moving the jitlib gui folders it'd be good with a blessing from @telephon or @adcxyz (I also can't see any risk with it, but what do i know)

[telephon]

@redFrik no problem from my side.

[bagong]

@redFrik , I think you are just less bold than I ;) But a PR can always be rejected, so nothing wrong with trying it, right? I am most unsure as to the correct identification of the hardware/compiler combination that go with your flags. Does

${CMAKE_COMPILER_IS_GNUCXX} AND ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l"

and

${CMAKE_COMPILER_IS_GNUCXX} AND ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv6l"

sound right?

There could be other systems with this architecture, but maybe they would also require your flags?

[bagong]

@thumbthumb , can we close this?

[vivid-synth]

@thumbthumb ^^

[gusano]

@vivid-synth I'd say leave it opened until we add those flags for when building on rpi

[nhthn]

Let's get on that. We should make SC installation easy on RPi, Bela, etc. because the SC target audience is likely to contain a lot of users who do hardware synths and installations.

[gusano]

Just realised that the flags are in master already and the build infos up-to-date in the wiki.. closing.