Building in macOS 11.0 Big Sur

theo · November 23, 2020, 7:25pm

Hey - I can confirm this. Looks like _FMOD_System_GetSpectrum was removed from the fmod api quite a while ago. We’ll need to find a replacement function using the newer approach.

See: https://stackoverflow.com/a/41005672

Unfortunately the transitioning documentation has been removed from the fmod site.

Kroggel · November 24, 2020, 12:01pm

thank you, runs fine on M1 with the fix

And if I may add to the hype. And in case anyone cares. It feels blazing fast on an macbook air m1 with 8gb. Comming from an 2018 13“ pro with 16gb ram. It took way longer for the inital compile and ran extreemly hot in debug. This one seems 10 times faster. I am more on the nooby side in terms of the internals but if somehow openframeworks becomes native m1 it should be blazing fast.

TravelByRocket · November 23, 2020, 8:54pm

Should I get this on the github issue tracker or are you already tracking it?

theo · November 24, 2020, 6:30pm

Thanks @TravelByRocket !
I’ve added it to the 0.11.1 list here:
https://github.com/openframeworks/openFrameworks/issues/6483

TravelByRocket · November 25, 2020, 7:51pm

Any suggestions on a workaround in the meantime? I really don’t need anything related to sound to work for the project I want to get going on.

theo · November 25, 2020, 9:07pm

Any suggestions on a workaround in the meantime? I really don’t need anything related to sound to work for the project I want to get going on.

If you comment out these lines in ofSoundPlayer.cpp

and this line in ofSoundPlayer.h

It shouldn’t give you anymore linking errors.
Hope that helps!

theo

TravelByRocket · November 25, 2020, 10:02pm

THANK YOU x1000

lmtanco · November 27, 2020, 6:57pm

Hi Theo, many many thanks for the help!

It worked for me, only I also had to comment out:

This line from ofFmodSoundPlayer.h:

And all these lines from ofFmodSoundPlayer.cpp, from here:

…up to here:

to get it linking.

BW,

Luis.

0a01.wait · November 27, 2020, 9:37pm

Thanks for that. It corrected the problem for the specific project, but is there a way to set the updated install_name_tool string for every existing and new project? I did a full disk file contents search and didn’t seem to find it in any location that would imply global scope for Xcode. TIA.

theo · November 28, 2020, 9:43pm

I found the modern FMOD API calls to replace that missing function.
You can see the changes in this PR if you need to use FFT with Big Sur in the meantime:

theo · November 28, 2020, 9:49pm

If you wanted to replace it for new projects / examples:
You would change this line here in scripts/templates/osx/emptyExample.xcodeproj/project.pbxproj

github.com

openframeworks/openFrameworks/blob/patch-release/scripts/templates/osx/emptyExample.xcodeproj/project.pbxproj#L3402


			<key>runOnlyForDeploymentPostprocessing</key>
			<string>0</string>
			<key>shellPath</key>
			<string>/bin/sh</string>
			<key>shellScript</key>
			<string>mkdir -p "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/Resources/"
# Copy default icon file into App/Resources
rsync -aved "$ICON_FILE" "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/Resources/"
# Copy libfmod and change install directory for fmod to run
rsync -aved "$OF_PATH/libs/fmodex/lib/osx/libfmodex.dylib" "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/Frameworks/";
install_name_tool -change @executable_path/libfmodex.dylib @executable_path/../Frameworks/libfmodex.dylib "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/MacOS/$PRODUCT_NAME";


echo "$GCC_PREPROCESSOR_DEFINITIONS";
</string>
		</dict>
		<key>E4C2427710CC5ABF004149E2</key>
		<dict>
			<key>buildActionMask</key>
			<string>2147483647</string>
			<key>dstPath</key>
			<string></string>

to:
install_name_tool -change @rpath/libfmod.dylib @executable_path/../Frameworks/libfmodex.dylib "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/MacOS/$PRODUCT_NAME";

Then you can use the project generator to make new projects with this fix. Or with the advanced options enabled in the cog of the projectGenerator.app you can then do ‘update multiple’ and select the examples folder to update all the examples with this change.

theo · December 4, 2020, 12:10am

shotaro · December 6, 2020, 1:12am

Thank you so much for the solution of this.

I’m glad if anyone help me to direct how to replace fmodex dylib with the latest one.
I opened zip file and terminal is opened. and I’m not sure what to do next.

sorry for the beginner’s question, Any help will be greatly appreciated.

shotaro · December 6, 2020, 2:46am

I solved the problem by myself, thank you for the solution.

theo · December 31, 2020, 8:20pm

Here is what should be a BigSur / Apple M1 friendly version of 0.11.0.
Still working through a few kinks on our CI but I tested this version on both a Apple Silicon M1 mac with Xcode 12 and a Intel Mac running 10.14 with Xcode 11.

Please share any issues you run into in this thread.

Theo

Kroggel · January 1, 2021, 1:37pm

just had a quick test. seems to run fine here on m1 air base model. thank you very much

theo · January 2, 2021, 7:07pm

great - glad it works for you!

0a01.wait · January 3, 2021, 11:31pm

Tried the new build on 2020 Intel MacBook Pro w/macOS 11.0.1 - corrected the mode linker error. Thanks!

suyash · January 12, 2021, 6:27am

The new build worked for me on Intel based MacBook Pro - 13 inch - Big Sur running Xcode 12.3. Can this build be the official build now as I downloaded the official one today and ran into this bug ?Thanks for your hard work!

theo · January 13, 2021, 8:09pm

I think the Nightly Builds now should now be Apple M1 and Intel Big Sur compatible.

If anyone wants to give it a try here is the latest: https://openframeworks.cc/ci_server/versions/nightly/of_v20210113_osx_nightly.zip

Please let us know in this thread if you notice any bugs/issues.

Thanks,
Theo