Open Devilsparta opened 2 years ago
Anyone?
Anyone?
C++ modules aren't used often (and macOS isn't that popular in the Godot community), so it may take a while to find a solution to this.
cc @gramps
I've never had any issues with GodotSteam but this seems to be something OSX-specific. I also have no Mac to test it with. @SapphireMH handles that stuff for GodotSteam so he might have an idea why this happens.
We don't run into this particular issue with our own module, so I'd recommend you to compare your config.py and scsub file to ours and see if something there is strange or requires changing.
On first glance I can't see what's wrong but I don't have the time to deep dive into it.
Also please mention the version of MacOS, version of Scons, etc, that you are using, sometimes all it takes is an update to the buildtools to fix confusing errors, I've been there.
FYI, I had a similar issue on Linux but the only error I was seeing was
.../projects/godot/bin/godot.linuxbsd.editor.x86_64.llvm: symbol lookup error: .../projects/godot/bin/liblisp.linuxbsd.editor.x86_64.llvm.so: undefined symbol: _ZN10MethodBind12_set_returnsEb
My understanding is that this has to do with use of the templated MethodBind
class and the template not being instantiated for whatever reason. I resolved my issue by making my module statically linked but having all my actual implementation details in a shared library.
I'm hitting this too. A few clarifications:
Latest macOS Ventura, 4.0.3-stable, scons v4.5.2.
Just tried the summator tutorial on my Windows PC and ran into the same linker errors. I don't have a Linux install to try, but either this tutorial for modules only works on Linux, or something has changed in Godot 4 to prevent this tutorial from working. Or we're all doing something wrong. :)
I looked at Godot's SCsubs for its built-in modules and unfortunately none of them seem to support this shared library approach. Do engine module devs all wait for 30s each time they make a small change?
I also looked at @SapphireMH's SCsub and godotsteam doesn't seem to support this approach either.
Lastly I looked through @Zylann's SCsub and some Discord history, and while I found fellow developers complaining about slow SCons build times for modules, I couldn't find any trace of people who have successfully tried the shared library approach as described in the godot docs.
Unfortunately I'm new to SCons and I'm not sure how to debug this any further. It's truly impressive that something like godot_voxel exists at all with 30s build times for even small module changes.
The code to build Summator as a shared library wasn't extensively tested on all platforms and is likely broken in its current state in 2023. It was added years ago by @touilleMan in https://github.com/godotengine/godot-docs/commit/927ef4576ccfc9a184728620fe16ae9a46944f50.
I looked at Godot's SCsubs for its built-in modules and unfortunately none of them seem to support this shared library approach.
This is planned to be implemented at some point. See https://github.com/godotengine/godot-proposals/issues/1796.
Do engine module devs all wait for 30s each time they make a small change?
You can optimize the linking setup significantly on Linux by using a different linker such as mold, or get a faster CPU. It can pay for itself over time if you're a professional developer :slightly_smiling_face:
macOS has a commercial version of the mold linker available as sold. You could try its evaluation version for free.
You can speed up SCons itself on macOS using pyston_lite_autoload (see https://www.pyston.org/). That said, SCons is usually not the largest bottleneck in small incremental changes – it's the linking, which is done by the linker that's written in C/C++.
Thanks for your reply and suggestions. Good to know support for shared libraries is planned.
SCons is usually not the largest bottleneck in small incremental changes – it's the linking
On an M1 I'm seeing about 10s spent just in the scons: Building targets ...
phase where you see a percentage number going up, and then ~5s linking. This is after an incremental change to a small module. So your pyston suggestion could be a good one in my case.
On an M1 I'm seeing about 10s spent just in the
scons: Building targets ...
phase where you see a percentage number going up, and then ~5s linking
Does it improve if you use the progress=no
SCons option? I've found that progress reporting can slightly slow down the build process, especially on Windows with its slow console I/O.
Does it improve if you use the
progress=no
SCons option?
Unfortunately there's no improvement by hiding progress.
I'm leaning toward just trying to use GDExtension
if at all possible even though it's still a little raw, since a shared library workflow would be valuable to me if I can figure out how to make it do most of what I need to do.
Thanks again for your suggestions.
scons: Reading SConscript files ...
Auto-detected 16 CPU cores available for build parallelism. Using 15 cores by default. You can override it with the -j argument.
Found MSVC version 14.3, arch x86_64
Building for platform "windows", architecture "x86_64", target "editor".
NOTE: Developer build, with debug optimization level and debug symbols (unless overridden).
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
[ 50%] Linking Static Library modules\module_summator.windows.editor.dev.x86_64.lib ...
[ 96%] Linking Shared Library bin\summator.windows.editor.dev.x86_64.dll ...
[100%] progress_finish(["progress_finish"], [])
[100%] Linking Program bin\godot.windows.editor.dev.x86_64.exe ...
[100%] Linking Program bin\godot.windows.editor.dev.x86_64.console.exe ...
register_types.windows.editor.dev.x86_64.obj : error LNK2019: unresolved external symbol "void __cdecl _global_lock(void)" (?_global_lock@@YAXXZ) referenced in function "public: static void __cdecl ClassDB::register_class<class Summator>(bool)" (??$register_class@VSummator@@@ClassDB@@SAX_N@Z)
register_types.windows.editor.dev.x86_64.obj : error LNK2019: unresolved external symbol "void __cdecl _global_unlock(void)" (?_global_unlock@@YAXXZ) referenced in function "public: static void __cdecl ClassDB::register_class<class Summator>(bool)" (??$register_class@VSummator@@@ClassDB@@SAX_N@Z)
register_types.windows.editor.dev.x86_64.obj : error LNK2019: unresolved external symbol "void __cdecl _err_print_error(char const *,char const *,int,char const *,bool,enum ErrorHandlerType)" (?_err_print_error@@YAXPEBD0H0_NW4ErrorHandlerType@@@Z) referenced in function "public: static void __cdecl ClassDB::register_class<class Summator>(bool)" (??$register_class@VSummator@@@ClassDB@@SAX_N@Z)
register_types.windows.editor.dev.x86_64.obj : error LNK2019: unresolved external symbol "public: static void __cdecl Memory::free_static(void *,bool)" (?free_static@Memory@@SAXPEAX_N@Z) referenced in function "public: static void __cdecl ClassDB::_add_class<class RefCounted>(void)" (??$_add_class@VRefCounted@@@ClassDB@@SAXXZ)
I just tried it on windows and it also failed, maybe we should mark this feature on the documentation as deprecated so people don't waste their time.
Godot version
3.4.dev(dfdc2b3)
System information
MacOS
Issue description
My godot build with summator failed when I'm building it a shared library.
I'm using the 3.4 branch. The building enviroment is MacOS. I can build it to static library, but cannot build it a shared library.
My summator is exactly the same with the tutrial.
and my SCsub file is:
My terminal of scons command output is:
Please help me!! If you need any detail information, just replay and I will edit here.
Steps to reproduce
Put project downbelow in
godot/modules
and runscons target=release_debug platform=osx -j6
Minimal reproduction project
summator.zip