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.
I get the app running but there are tons of errors in the buildtime slide, is that normal?
Hi, can you share the errors you are seeing?
Ah that is helpful. Thanks!
Those Warnings are normal.
Though the header map one is something we probably should address soon.
Thank you theo! You are awesome!
@theo I’m very new in oF, can you give me a little guide of how achieve this?
Try the nightly downloads for osx linked at the bottom of:
if you are using Apple M1 and building with make (VSCode) it worths installing make using homebrew, so you use arm-apple-darwin20.2.0 instead of i386-apple-darwin11.3.0
to make it work I had to edit ~/.zprofile file and add new make to the PATH variable