[Bug]: Macos Arm64 Support
QuentinWidlocher opened this issue · comments
Godot version
4.2.1 stable
DebugDraw3D version
1.3.0
On which operating systems the error occurs
macOS
Using which renderers the error occurs
No response
Issue description
Maybe I'm missing something, but adding the debug_draw_3d.gdextension in the addons folder yields this error message when restarting godot:
core/extension/gdextension.cpp:911 - No GDExtension library found for current OS and architecture (macos.arm64) in configuration file: res://addons/debug_draw_3d/debug_draw_3d.gdextension
Failed loading resource: res://addons/debug_draw_3d/debug_draw_3d.gdextension. Make sure resources have been imported by opening the project in the editor at least once.
This two month old reddit post seems to indicate this addons isn't compatible with mac M1/2/3 ? I have a Macbook Air M2.
Steps to reproduce
N/A
Minimal reproduction project
N/A
Can you try changing all the .gdextension lines that start with macos = to macos.arm64 = ?
Or you can download an already updated file: debug_draw_3d.gdextension.txt (remove .txt from the extension). Replace the original file with it.
Tried the new file, renamed to gdextension and restarted godot. Still getting:
core/extension/gdextension.cpp:911 - No GDExtension library found for current OS and architecture (macos.x86_64) in configuration file: res://addons/debug_draw_3d/debug_draw_3d.gdextension
Failed loading resource: res://addons/debug_draw_3d/debug_draw_3d.gdextension. Make sure resources have been imported by opening the project in the editor at least once.
Were there any other errors before this error?
No, this is the only error that appears int he console output as soon as the project loads. I've already commented out all calls or references to the old classes. Happy to help troubleshoot or test fixes.
Added it to a blank project via the AssetLib, same error (but also spam about the example file calling methods that dont' exist yet).
I definitely ran GDExtension earlier by specifying .dylib.., but the example specifies the .framework folder. https://github.com/godotengine/godot-cpp/blob/dd62b9685fbc9b733a25e26a788b5d7f3212a804/test/project/example.gdextension#L8
I will be able to create these templates later.
or perhaps you can remove the .dylib extension from the path 🤷♂️
No luck, tried to remove the .dylib from the path. Same error.
Tried to copy/paste the contents of the earlier gdextension you linked, same error.
With the updated .gdextension from the previous comment, I was able to run the editor in Monterey x86_64.
Could it have anything to do with Sonoma? Here are my specs.
Here is the output of a fresh install from assetLib and replaced the gdextension file with the one linked in the previous post.
Could it have anything to do with Sonoma?
Only if apple disallowed direct use of the combined libraries.
replaced the gdextension file with the one linked in the previous post.
No no, I meant my .gdextension #34 (comment)
That file from the example cannot be run with my libraries at all.
Ah I see, my mistake. Yes that one seems to work now. Which is odd because last night I tried it as well, fresh install, download the .txt and rename it in get info, but it seems to work now. Thankyou!
seems to work now
While testing I had a similar problem. I updated the file, restarted the project in the virtual machine and nothing worked, although the file seemed to be updated. From the second start the library started working 🤷♂️
but it seems to work now. Thankyou!
That's good to hear!
It would also be nice to know if the library works with arm64. @QuentinWidlocher, does the library work with arm64 and updated .gdextension?
I created a new project, downloaded the addon from the asset store and the replaced the debug_draw_3d.gdextension by the one you provided in your comment. I still have the same exact error when opening the demo scene in the addon
You both seem to have no problem on x86 macos, but even if the universal build should work with arm64, it doesn't for me 😕
So if you actually have those lines in the .gdextension file, then I can only suggest restarting the editor again for now 🤷♂️.
In my case (M1 Max, Sonoma 14.2), the architecture configuration issue was solved by inverting the order of the macOS-related lines from
# debug
macos.arm64 = "libs/libdd3d.macos.editor.universal.dylib"
macos.x86_64 = "libs/libdd3d.macos.editor.universal.dylib"
to
# debug
macos.x86_64 = "libs/libdd3d.macos.editor.universal.dylib"
macos.arm64 = "libs/libdd3d.macos.editor.universal.dylib"
and restarting the editor.
by inverting the order of the macOS-related lines from
oooh.. That's really bad.
Because if you change their order, then the library is no longer recognized in x86_64.
I see. This seems more like a Godot-related issue in reading the extension configuration file.
Until it is corrected, we could invert the order to have the extension working, waiting for the main fixing to arrive.
Can confirm that by replacing #s with ; for comments, the config file works even without inverting the order of the macOS-related lines 🎉
So we will not have to wait for Godot after all 😀
Very frustrating, Godot never showed any error that # debug is not a comment (godot read it as #debugmacos).
even without inverting the order of the macOS-related lines
Actually you can avoid using separate lines for x86_64 and arm64.
Anyway, I'll try to release 1.3.1 soon.
Huge FPS! (I guess macOS VM requires a more powerful PC...)
vmware_RleUu3VzD4.mp4
Btw 1.3.1 is already available.