godotengine / godotengine/godot-cpp

Automatically detecting if GODOTCPP_TARGET is misconfigured (missing)

Open
#1,856 10 comments 0 reactions 1 assignee Claimed by @enetheru View on GitHub
Dominant language
C++
Stars
2.7k
Forks
809
Avg merge
1d 3h
Merged PRs (30d)
8

Description

### Godot version

4.5

### godot-cpp version

4.5 (e83fd0904c13356ed1d4c3d09f8bb9132bdc6b77)

### System information

macOS 15.6 (24G84)

### Issue description

I had a pretty silly mistake in my build configuration as I was not setting `-DGODOTCPP_TARGET=template_release` in release CMake builds. That for some reason made only Mac release game exports crash. Everything else somehow still worked (Windows, Linux, and Mac debugging). It took me about 3 days to track down this "simple" build misconfiguration.

So as it is so, so difficult to debug this problem, I have a suggestion that at least one godot-cpp header could be set up to cause the build to immediately fail if mismatched flags are detected. This is what I used to finally after a long day today manage to track down the problem to be build flags, but I'm not sure if these would be in general the right combination of flags to check:

```c++
#ifdef NDEBUG
#ifdef DEBUG_ENABLED
#error "Invalid configuration of Godot build flags (release incorrect)"
#endif
#else
#ifndef DEBUG_ENABLED
#error "Invalid configuration of Godot build flags (no debug)"
#endif
#endif
```

And interestingly enough I have had this problem in my build flags since like Godot 4.3 but it is only now causing a problem on Mac with Godot 4.5.

### Steps to reproduce

- Build a GDExtesion for Godot 4.5 on Mac with CMake using `-DCMAKE_BUID_TYPE=RelWithDebInfo` (or another non-debug build type)
- Export the project for Mac as a non-debug game
- Run the game and get an immediate crash. The crash callstack *sometimes* had useful info (but often it was totally useless):

```
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libthrive_extension_without_avx.dylib 0x10e62b564 0x10e628000 + 13668
1 libthrive_extension_without_avx.dylib 0x10e66f1a8 0x10e628000 + 291240
2 libthrive_extension_without_avx.dylib 0x10e64cbd4 0x10e628000 + 150484
3 libthrive_extension_without_avx.dylib 0x10e632260 0x10e628000 + 41568
4 Thrive 0x1081bade8 GDExtensionManager::initialize_extensions(GDExtension::InitializationLevel) + 84
5 Thrive 0x1056123b8 Main::setup2(bool) + 15008
6 Thrive 0x105606f94 Main::setup(char const*, int, char**, bool) + 95644
```

That at least hints to where the problem was but I could not see any problems with my method registration nor was I proficient enough in Mac debugging tools to be able to catch the problem (funnily enough I had to work on a different project on Linux before I was able to find this mistake as then I was able to use valgrind to pinpoint the memory allocation problems the mismatched flags caused).

### Minimal reproduction project

Any project with at least one call to `ClassDB::bind_method` should be sufficient to trigger the issue.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.