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!
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.
I’ve trying to use this new folder, but I keep getting the same error no matter which project I use. I’m not using XCode because it’s for a class and we are trying to be inclusive to all OS so VSCode it is and here’s the screenshot of the errors because I truly don’t know what to do.
Welcome to the OF forum!
I think the first step would be to try it with Xcode just to make sure it runs on your system. Sometimes Xcode installs command line tools which the other compilers like VSCode needs. ( that could be causing the missing libstdc++ error you are seeing ).
Could you try?:
- installing the latest Xcode
- Then Try running some of the OF examples
- Then if that works try VSCode again ( VSCode might also need an update )
I tried the examples on Xcode and they all run, which is why I’m confused as to why it wouldn’t work? It still gives me the same errors (I reinstalled both XCode, the Command Line Tools from XCode and VSCode) and I’m really frustrated at this point.
Are you using the nightly builds at the bottom of this page?:
I just tried with VSCode and the nightly builds work and run fine. I think that error might be related to the older 0.11.0 release which isn’t Big Sur compatible.
I hope that helps!
tried to build an example on Apple Silicon M1 but using Qt Creator with no luck. Using nightly build It builds with no errors, bu when it runs I get errors:
dyld: Library not loaded: @rpath/libfmod.dylib Referenced from: /Users/dumski/Developer/of_v20210201_osx_release/examples/3d/3DPrimitivesExample/bin/3DPrimitivesExample_debug.app/Contents/MacOS/3DPrimitivesExample_debug Reason: image not found 22:44:19: The program has unexpectedly finished.
Could you help?
Ahh I think we need these equivalent commands for qtCreator:
You can see here that it is assuming the files should be copied to Contents/MacOS and not Contents/Frameworks :
Thanks, I tried a quick dirty approach and copied libfmod.dylib to Frameworks dir inside the app but it didn’t work. Same error. Not sure If I understand right – where should be the libfmod.dylib exactly (inside the app bundle)?
You will also need to add the rpath to the executable so it knows to look there.
If you are in the
bin/ folder this should work:
install_name_tool -add_rpath "@executable_path/../Frameworks" *.app/Contents/MacOS/*
You can also replace the wildcards with the actual app name
Actually this has led me to finding a better solution which could allow us to skip the post-build script step.
For right now for a fresh project you just have to do this once for the dylib In
install_name_tool -id @loader_path/libfmod.dylib libfmod.dylib
Because we should be looking in Frameworks/ and not the MacOS folder I am going to set it to:
install_name_tool -id @loader_path/../Frameworks/libfmod.dylib libfmod.dylib
But for your download the first command should be what you need ( with the dylib being copied to the Contents/MacOS folder )
Exactly, the working solution for me was also:
install_name_tool -add_rpath "@executable_path" *.app/Contents/MacOS/*
because the libfmod.dylib is placed inside MacOS folder after building with Qt Creator. This command (executed after build) allows me to run the app. But when I try to compile 3DPrimitivesExample get another error:
[ error ] ofAppGLFWWindow: 65544: Cocoa: Failed to find service port for display
which is related to some GL stuff I think…
That is weird. I wonder if it is because QTCreator is using the x86_64 build environment and not arm64?
If you run the same example with Xcode does it build and run fine for you?
Unfortunately, don’t have Xcode environment configured for OFX, so I cannot check that for you. But yes, Qt Creator uses x86_64 clang. Frankly, I don’t know if there is arm64 build environment here in Qt Creator…
EDIT: I started to configure Qt Creator’s build environment for arm64 architecture (using arm64 clang from Command Line Tools). Now I have some problems to set paths for all includes but I believe I’ll manage this within some hours. I will let you know if the error persists for arm64 executables.
Ehh, I’m having problems configuring qt creator for native arm64 build for Apple Silicon. Maybe anyone have links to some kind of a guide for that? I assume that M1 is no new that no information are available… @theo - did you manage to native compile OFX on M1 already?
Edit: I built empty example for native arm64 arch with Xcode and can confirm that these errors are the same:
[ error ] ofAppGLFWWindow: 65544: Cocoa: Failed to find service port for display 2021-02-03 18:46:58.192258+0100 emptyExampleDebug[12681:513592] Metal API Validation Enabled 2021-02-03 18:46:58.216879+0100 emptyExampleDebug[12681:513592] fopen failed for data file: errno = 2 (No such file or directory) 2021-02-03 18:46:58.216920+0100 emptyExampleDebug[12681:513592] Errors found! Invalidating cache... [ error ] ofAppGLFWWindow: 65544: Cocoa: Failed to find service port for display
I can confirm also that the ofAppGLFWWindow error shows up with native arm64 build but not prevent app from running. For x86_64 build in Qt Creator some examples crash (like 3DPrimitivesExample) with that error.
So I think when I manage to configure Qt Creator build environment for native arm64 OFX build the error won’t be a problem.
Looks like it is still in progress from what I can tell: https://bugreports.qt.io/browse/QTBUG-85279
The nightly builds do currently work with Xcode and native arm64 on M1.
I am guessing VSCode ( which you can generate with the projectGenerator ) and which uses the OF make files would work natively too.
Ok. I think I need to shift to Xcode since it allows me to build natively. Thanks a lot!
Fixed by downloading of_v.11 nightly build (of_v20210221_osx_release).
I ran into this issue using of_v0.10.1 and of_v0.11.0. Changing the build script did not work for me.
I’m now compiling some projects in XCode 12 / Apple M1 it is running great (openFrameworks latest / patch-release branch).
The only issue is the retina windows are tiny, seems like they are drawn in absolute pixels 1:1 and not scaled 1:2
Anybody else having this issue?
@dimitre I think that is a known issue and hopefully something we can work on for 0.12.0
Currently enabling retina will give you a window with the absolute pixel dimension you request.
Once you have your retina window you can query ofAppGLFWWindow for the pixel scale and then adjust all the rendering to compensate.
We had considered handling it all for the user and doing some sort of global scale to compensate, but it doesn’t cleanly work for things like fonts etc.
I think for 0.12.0 we could at least get the window size being the same appearance regardless of retina / non-retina and maybe have a bit better support for some other parts of it. The tricky thing also is when you move your app window to a retina screen from a non retina screen or vice-versa.
If you think there is a regression from 0.11.0 def post an issue though.
I might be misunderstanding the problem.