Building for MacOS fails

[emlynmac]

Describe the bug Following the instructions here: https://github.com/jamulussoftware/jamulus/blob/master/COMPILING.md#macos leads to an error at the xcodebuild phase:

PhaseScriptExecution Qt\ Qmake .xcode/Jamulus.build/Release/Qt\ Preprocess.build/Script-5E618435888B9D49F8540165.sh
    cd /Volumes/Data/Users/emlyn/code/jamulus
    /bin/sh -c \"/Volumes/Data/Users/emlyn/code/jamulus/.xcode/Jamulus.build/Release/Qt\ Preprocess.build/Script-5E618435888B9D49F8540165.sh\"
make: `Jamulus.xcodeproj/project.pbxproj' is up to date.

PhaseScriptExecution Qt\ Preprocessors .xcode/Jamulus.build/Release/Qt\ Preprocess.build/Script-7EF0942E79C014DCEC8976BC.sh
    cd /Volumes/Data/Users/emlyn/code/jamulus
    /bin/sh -c \"/Volumes/Data/Users/emlyn/code/jamulus/.xcode/Jamulus.build/Release/Qt\ Preprocess.build/Script-7EF0942E79C014DCEC8976BC.sh\"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -msse  -I. -Isrc -Ilibs/opus/include -Ilibs/opus/celt -Ilibs/opus/silk -Ilibs/opus/silk/float -Ilibs/opus/silk/fixed -Ilibs/opus -I/usr/local/Cellar/qt@5/5.15.2/lib/QtWidgets.framework/Headers -I/usr/local/Cellar/qt@5/5.15.2/lib/QtMacExtras.framework/Headers -I/usr/local/Cellar/qt@5/5.15.2/lib/QtGui.framework/Headers -I/usr/local/Cellar/qt@5/5.15.2/lib/QtNetwork.framework/Headers -I/usr/local/Cellar/qt@5/5.15.2/lib/QtXml.framework/Headers -I/usr/local/Cellar/qt@5/5.15.2/lib/QtConcurrent.framework/Headers -I/usr/local/Cellar/qt@5/5.15.2/lib/QtCore.framework/Headers -I. -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/AGL.framework/Headers -I. -I/usr/local/Cellar/qt@5/5.15.2/mkspecs/macx-clang -F/usr/local/Cellar/qt@5/5.15.2/lib -c libs/opus/celt/x86/pitch_sse.c -o pitch_sse.o
In file included from libs/opus/celt/x86/pitch_sse.c:34:
libs/opus/celt/stack_alloc.h:39:2: error: "Opus requires one of VAR_ARRAYS, USE_ALLOCA, or NONTHREADSAFE_PSEUDOSTACK be defined to select the temporary allocation mode."
#error "Opus requires one of VAR_ARRAYS, USE_ALLOCA, or NONTHREADSAFE_PSEUDOSTACK be defined to select the temporary allocation mode."
 ^
1 error generated.
make: *** [pitch_sse.o] Error 1

To Reproduce Follow the instructions on Xcode 12.5 / macOS Big Sur 11.4

Expected behavior Clean build, no errors

Operating system macOS 11.4, Xcode 12.5, qt5 from home-brew

Version of Jamulus master as of 9am PDT June 7 2021

Additional context Looks like some OPUS compiler flags need to be defined somewhere

[npostavs]

Running make clean (EDIT: or whatever XCode equivalent is) first might help (assuming this isn't a totally fresh checkout).

Otherwise I'm not sure how USE_ALLOCA isn't getting defined, because it gets added to OPUS_DEFINES unconditionally.

The bit where x86 gets added to CONFIG for macOS does look a little suspicious though.

[emlynmac]

A totally fresh checkout unfortunately. I'm looking at the generated qt_preprocess.mak and see the right DEFINES at the top. However, this probably should be CFLAGS and not DEFINES? It builds fine then...

[emlynmac]

Adding: CFLAGS += DEFINES at line 179 in Jamulus.pro seems to help, but I'm not sure if that is how this should be fixed...

[hoffie]

Thanks for the report.

Just a short note: The official Mac binaries are currently built with Xcode 11.7 (maybe with 12.1 soon) as those are the last versions which still ship SDK 10.15. The latter is the highest version which is supported by Qt5 right now.

It would still be interesting to find the cause for this issue though. However, even if found and fixed, Qt5 may show problems with newer SDKs.

Any specific reason for building yourself -- development?

cc @dcorson-ticino-com who has recently worked on Qt6 compatibility and @softins who has most-recently handled the Xcode version pinnings.

Adding: CFLAGS += DEFINES at line 179 in Jamulus.pro seems to help, but I'm not sure if that is how this should be fixed...

Yeah, the log you posted does not seem to contain any defines in the clang call, which is strange. I could imagine that this is indeed caused by a Qt/qmake incompatibility with SDK 11.3?

[emlynmac]

Interesting, I'll try with latest QT and see if that works. - never mind, I'll not do that yet now I see that is a WiP.

As for why, I'm hoping to dig into this: https://github.com/jamulussoftware/jamulus/discussions/1840

I want to make multi-track input more flexible. About a year ago, I was helping with getting multi-channel mixers working and I'd really like to have the possibility to have them as discrete mixable channels.

[dcorson-ticino-com]

I made the necessary changes to get Jamulus to compile under Qt6.1.0 without errors locally.
The github autobuild for Mac is made without errors, but as I have no Mac I can't test the results. You can download the Mac binary at https://github.com/dcorson-ticino-com/jamulus/suites/2929013840/artifacts/65759590 For the other platforms I have not yet been able to get the autobuilds using Qt6 to run without errors.

[emlynmac]

Thanks @dcorson-ticino-com - I'll pull your repo and work with that one then for now.

are there plans for qt6 to get merged soon or later?

[DavidSavinkoff]

I think it is better to drop Qt, especially for MacOS, and use native programming for MacOS. I watched a Apple seminar where they said not to use wrappers around their libraries (Qt yeah). I think that keeping up with MacOS using Qt will be bad for Jamulus as a whole. Better to drop Qt, or stay with Qt5, than move to Qt6.

[dcorson-ticino-com]

Programming just for a minority portion of the computer users out there, or maintaining multiple code bases, no thank you. If not Qt, then another platform that runs at least on Win10, Linux and Mac.

[dcorson-ticino-com]

are there plans for qt6 to get merged soon or later?

@emlynmac For the moment the idea is to see if Qt6 solves the very opaque problems we are now seeing on Macs. If that is the case I'm sure transferring to Qt6 will go quickly. The problem is that Qt6 does not support much of the legacy Mac hardware we are used to supporting.

If you get the Qt6 version running please let us know how it behaves, both from the UI problems we have seen and the degradation of audio quality over time some users are seeing. It is very strange that this is only manifesting itself on newer Mac units and not at all on the other platforms.

[emlynmac]

Qt6 version compiled happily for me and seems to run. Need to move the build to my main music Mac next time we do band and see how it behaves.

Update- I've got it looping back my local audio via the server and will let it run for the day while I work. So far it's going fine.

[henkdegroot]

I had a similar problem on my system when manually running the xcodebuild build command. As a knew the "autobuild" is working fine, I thought about running that script and that works for me.

So instead of running "xcodebuild build", I just run ./mac/deploy_mac.sh. (from the folder I downloaded the source code into)

Guess somewhere in that script a variable is set correct which makes things work.

[dcorson-ticino-com]

Update- I've got it looping back my local audio via the server and will let it run for the day while I work. So far it's going fine.

The problem might be related to if Jamulus or its windows are open in the background. If you can, please try if there are audio problems or increasing memory usage with: settings window open in foreground settings window open in background Jamulus in the background Jamulus in the foreground.

[ann0see]

Closing since this issue is related to missing Qt6 support.

[ann0see]

Re-opening as I can reproduce it with Qt 6.3.1 on Xcode 13.3.1

[ann0see]

Ok. git bisect gave this as bad commit: https://github.com/jamulussoftware/jamulus/commit/28a66e21e7d37c04f38786a9c7d59b55fadd7126

Tagging @npostavs