Building in macOS 11.0 Big Sur

Has anyone found a solution to the Apple Mach-O Linker Error in macOS 11 Big Sur?

I do realize the OS was released yesterday, and I have only installed it on one of my computers :wink:

2 Likes

some discussion here - the current solution posted by thel3l is very complicated

I haven’t looked at this recently but will take another look this week (cc @Theo) since it’s pretty urgent to get a better solution that doesn’t involve so much work…

1 Like

Hey @naero - could you share your linking errors?

Curious if they are the same ones Zach posted ( which was from the Apple Silicon Dev kit ) or different ones?

I am ordering one of the new Silicon Mac Minis but will see if I can get 11.0 running on a spare machine in the meantime.

Cheers!
Theo

ah to clarify my issues were just with compiling on Big Sur generally (on intel Mac)

Of course. This is also on an Intel Mac.

Okay I got it working.

  1. replace your fmodex dylib in libs/fmodex/lib/osx/ with the latest one here: libfmodex.dylib.zip (638.6 KB) ( Make sure to unzip it. )
  2. in the build phase Run Script ( second to last ) change:
install_name_tool -change @ executable_path/libfmodex.dylib @executable_path/../Frameworks/libfmodex.dylib "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/MacOS/$PRODUCT_NAME";

to:

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

That should be it. The main issue is that we are using a pretty old fmodex dylib and it still links with libstdc++.6.dylib. The newer fmod dylib doesnt have that issue.

Will work on a PR for this and will link to this post in the Github issue.

9 Likes

This works perfectly. Thank you!

nice

Very cool!

Hate to gush about this sort of thing - but its really exciting to see a technological step like this. Hopefully we’ll be seeing more RISC / ARM based computers for other platforms too

Is the new Xcode on Big Sur compiling Universal versions of oF apps? Anyone testing on a M1 yet? If it compiles to Universal/M1 native are oF apps getting a performance boost on the new systems?

Edit: Are Macs exciting again?

1 Like

Is it possible to make this change in the AppCode Project Settings page as well? I am having trouble finding the equivalent “Run Script”

@ayruos not yet this is something we will be working on soon. ( see: https://github.com/openframeworks/apothecary/issues/161 )

My M1 Mac Mini is arriving tomorrow so hoping to be able to start work on it shortly after.
At this point I think it makes sense to drop 32bit and have 64bit/arm64 universal libs/apps going forward.

I believe you have to set it in the Xcode project not AppCode ( which uses the Xcode project if I understand right? ). Or if it doesn’t, someone where in AppCode there must be a run script phase doing install_name_tool as the App wouldn’t run without it. If you can search your project file maybe in a text editor for install_name_tool you might be able to track down those lines.

Here is the location in Xcode to change those lines:

I found it, you have to change the Project view to files, as it hides the project.pbxproj file by default. It is located in

projectname/projectname/projectname.xcodeproj/project.pbxproj

after changing this, it will now build, but I get:

arch -e DYLD_LIBRARY_PATH=/Applications/of_v0.11.0_osx_release/apps/myApps/blockBoxes/bin -e DYLD_FRAMEWORK_PATH=/Applications/of_v0.11.0_osx_release/apps/myApps/blockBoxes/bin -x86_64 /Applications/of_v0.11.0_osx_release/apps/myApps/blockBoxes/bin/blockBoxesDebug.app/Contents/MacOS/blockBoxesDebug
dyld: Library not loaded: @rpath/libfmod.dylib
  Referenced from: /Applications/of_v0.11.0_osx_release/apps/myApps/blockBoxes/bin/blockBoxesDebug.app/Contents/MacOS/blockBoxesDebug
  Reason: image not found

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

at run time. I also get this error if I build and run in xcode.

I think the problem is the libfmod.dylib is not being copied to the built project.app/Contents/Resources folder.

I had to change

runOnlyForDeploymentPostprocessing = 1;

to 0 to force the command to run. It is now copying the libfmod.dylib file into the

project.app/Contents/Frameworks folder.

otool -L blockBoxesDebug

shows that it is looking here for the lib

@rpath/libfmod.dylib (compatibility version 1.0.0, current version 1.0.0)

but it still fails at runtime with

arch -e DYLD_LIBRARY_PATH=/Applications/of_v0.11.0_osx_release/apps/myApps/blockBoxes/bin -e DYLD_FRAMEWORK_PATH=/Applications/of_v0.11.0_osx_release/apps/myApps/blockBoxes/bin -x86_64 /Applications/of_v0.11.0_osx_release/apps/myApps/blockBoxes/bin/blockBoxesDebug.app/Contents/MacOS/blockBoxesDebug
dyld: Library not loaded: @rpath/libfmod.dylib
  Referenced from: /Applications/of_v0.11.0_osx_release/apps/myApps/blockBoxes/bin/blockBoxesDebug.app/Contents/MacOS/blockBoxesDebug
  Reason: image not found

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

Have you tried updating xcode?

worked it out, the updated file is libfmodex.dylib the rpath in the binary is @rpath/libfmod.dylib

Thank you Theo! You saved me!

Hi this, really saved me thank you!

I got it to work by following your instructions in Xcode. But when I want to use vscode it gives me the error:

Undefined symbols for architecture x86_64:
“_FMOD_System_GetSpectrum”, referenced from:
ofFmodSoundGetSpectrum(int) in libopenFrameworksDebug.a(ofFmodSoundPlayer.o)
ld: symbol(s) not found for architecture x86_64

As I’m new to open frameworks i dont really know how to fix that.

Quick nooby question. Even when not compiling universal. Is it possible to use oF on m1 macs with Xcode right now and just compile for intel and run the code through rosetta somehow?