I have run Sonic Pi builds on my Mac for several years, but recently my setup has been all screwed up. Currently I am still running High Sierra, although I can also access a viertual Mohave machine. It all started when an automatic homebrew install upgraded everything and switched to qt 5.13.0 It also objected to the Xcode version I was running so I upgraded this to the latest that would run on High Sierra version 10.1 (including Mac SDK10.14) together with the associated command line tools.
Previously I have built using brew installs for qt, qscintilla2, but built (for historical reasons) qwt-6.1.4 myself., and everything has worked fine.
With the latest 3.2dev, which builds fine for me on Ubuntu and on Raspberry Pi4 under Raspbian Buster, it builds fine on My mac, but when I try and run it, (initially from the command line at
Sonic\ Pi.app/Contents/MacOS/Sonic\ Pi
it launches the splash screen, which after a few seconds has a rotating ball cursor and doesn’t respond. However if I look at the logs, everything appears to launch OK. There are no unexpected errors and the logs announce that Sonic Pi is running, as are m2o, o2m, erlang and scsynth. If I ctrl-C the terminal window everything shuts down nicely including the Splash Screen. There are no errors shown on the system side on the Mac, and I am at a loss how to proceed.
If anyone has any suggestions I would be glad to have them.
Interestingly, I have an older iMac running El Capitan, and that builds and runs the latest version fine, using qt5.9.0, and Xcode 7.3.1 (with Mac SDK10.11)
Hi @robin.newman,
do you get the same issues when compiling v3.1?
I’m on Mojave and working with hand-installed Qt, Qscintilla and Qwt and am not seeing the issue you are, so there is hope somewhere!
Yes so it something in my configuration which is doing it. I’ve just tried hand installed qt, qwt and qscintilla2, but I still used brew boost libs as I hadn’t built supercollider, so didn’t have its libs for boost. But I’ve never used these before and it has been OK.
had enough with it for today now…
After a holiday break, I returned to look at this, and managed to isolate the problem. The Scope code was not working, and when called to refresh, was going into a loop which froze the gui program, although the ruby side of the app was still working OK. I suspected the boost libraries, especially as Sam told me that he built his system using the boost libraries in the Supercollider source code. I was using the brew installed boost libraries, which had been upgraded to version 1.70.0 Supercollider used an earlier version, and this mismatch was causing the problem.
In fact I decided to use the later version, and built Supercollider from source with a flag to make it use the system boost library (ie that installed by brew) rather than the external boost library built into Supercollider.
In case anyone else is doing their own mac build I built SC using
cmake -G Xcode -DCMAKE_PREFIX_PATH=brew --prefix qt5-DSYSTEM_BOOST=ON ..
and
cmake --build . --target install --config Release
Alternatively, you can build supercollider using the built in external boost library (by omitting the DSYSTEM_BOOST=ON, and remove the brew installed boost libraries. In this case you need to alter the SonicPi.pro file to include links to the supercollider external boost libraries.
In my case I added:
LIBS += -L/Users/rbn/srcNew/Supercollider/external_libraries/boost/libs
INCLUDEPATH += /Users/rbn/srcNew/Supercollider/external_libraries/boost/
DEPENDPATH += /Users/rbn/srcNew/Supercollider/external_libraries/boost/
It’s as broad as it is long which method you use. The important thing is that the boost libraries match for Supercollider and for the scope code in Sonic Pi.
I’m now a happy bunny again with a working 3.2dev on my Mac Book Pro.
ADDENDUM
IF you want to build a self contained relocatable Mac app, then using the Supercollider built in external boost libraries is probably easier in the long run, as the boost bits are included in scsynth. If you build with the brew boost library then you will have to add the relevant libraries into the final Mac app bundle. For something that will just run on your build computer it doesn’t matter.
2 Likes
I’m looking at this in detail now. I’m confident I can fix the Mac build problems in short order.