Godot version
4.5.1.stable.official.f62fdbde1
godot-cpp version
4.5 commit: da26c17
System information
macOS (Intel x86_64), Clang compiler.
Issue description
Linking error on macOS (Clang x86_64): missing TLS wrapper __ZTW symbols for Wrapped class
I am encountering a runtime linking error when compiling a GDExtension on macOS (Intel x86_64) using Clang against the latest godot-cpp master branch (targeting Godot 4.5.1).
Despite compiling both godot-cpp and my extension with target=template_debug and ensuring -fvisibility=default is set, the linker fails to find the Thread Local Storage (TLS) wrapper functions for the godot::Wrapped class variables when loading the dylib.
Error Message:
Error: Can't open dynamic library: .../libjrpg_core_sdk.dylib.
Error: dlopen(...): symbol not found in flat namespace '__ZTWN5godot7Wrapped34_constructing_extension_class_nameE'
Investigation & Findings:
- I inspected the generated static library
libgodot-cpp.macos.template_debug.x86_64.a using nm -a.
- The output shows that the
thread_local variables themselves are present (marked as S - data section), but their corresponding TLS wrapper functions (mangled as __ZTW...) are missing entirely.
- It appears that the macOS Clang compiler is optimizing out (dead-stripping) these TLS wrapper functions because they are not explicitly called within the
godot-cpp translation units.
- Adding
__attribute__((used)) to the variables in wrapped.cpp did not fix it.
Workaround:
I was only able to make it work by manually implementing the wrapper functions in wrapped.cpp via extern "C" to match the mangled names expected by the linker:
// Manual workaround in wrapped.cpp
extern "C" {
void* __attribute__((visibility("default"))) __attribute__((used))
_ZTWN5godot7Wrapped34_constructing_extension_class_nameE() {
return (void*)&godot::Wrapped::_constructing_extension_class_name;
}
// ... same for _constructing_class_binding_callbacks
}
This suggests that godot-cpp needs a more robust way to ensure these TLS wrappers are generated and exported in static libraries on macOS/Clang.
Steps to reproduce
- Clone
godot-cpp (master branch).
- Use Godot 4.5.1 (stable/official) to dump the
extension_api.json.
- Compile
godot-cpp on macOS (Intel x86_64) with Clang:
scons platform=macos target=template_debug arch=x86_64 use_llvm=yes
- Compile a GDExtension project linking against this library (also using
template_debug and clang++).
- Run the project in Godot Editor.
- Observe the
dlopen error in the console regarding symbol not found in flat namespace '__ZTW...'.
Minimal reproduction project
N/A
Godot version
4.5.1.stable.official.f62fdbde1
godot-cpp version
4.5 commit: da26c17
System information
macOS (Intel x86_64), Clang compiler.
Issue description
Linking error on macOS (Clang x86_64): missing TLS wrapper
__ZTWsymbols forWrappedclassI am encountering a runtime linking error when compiling a GDExtension on macOS (Intel x86_64) using Clang against the latest
godot-cppmaster branch (targeting Godot 4.5.1).Despite compiling both
godot-cppand my extension withtarget=template_debugand ensuring-fvisibility=defaultis set, the linker fails to find the Thread Local Storage (TLS) wrapper functions for thegodot::Wrappedclass variables when loading the dylib.Error Message:
Investigation & Findings:
libgodot-cpp.macos.template_debug.x86_64.ausingnm -a.thread_localvariables themselves are present (marked asS- data section), but their corresponding TLS wrapper functions (mangled as__ZTW...) are missing entirely.godot-cpptranslation units.__attribute__((used))to the variables inwrapped.cppdid not fix it.Workaround:
I was only able to make it work by manually implementing the wrapper functions in
wrapped.cppviaextern "C"to match the mangled names expected by the linker:This suggests that
godot-cppneeds a more robust way to ensure these TLS wrappers are generated and exported in static libraries on macOS/Clang.Steps to reproduce
godot-cpp(master branch).extension_api.json.godot-cppon macOS (Intel x86_64) with Clang:template_debugandclang++).dlopenerror in the console regardingsymbol not found in flat namespace '__ZTW...'.Minimal reproduction project
N/A