GodotExtension: SCons use_static_cpp inconsistent when building for linux and windows

[Nanowires]

Godot version

4.4-stable

godot-cpp version

4.4-stable

System information

Linux fedora 41

Issue description

I was trying to cross-compile a GodotExtension, which is dependent on a third party library. When build for linux everything went fine. But cross-compiling for windows reported, that it cannot find the library, although I specified the paths correctly. With verbose output I found out, that when building for windows, it wants to build a statically by default (use_static_cpp=true), while building for linux is shared by default (use_static_cpp=false).

Is there a reason behind this? Wouldn't it make more sense to have a consistent build option across systems?

Build for windows: scons platform=windows debug_symbols=yes

build for linux: scons platform=linux debug_symbols=yes

SConstruct file:

#!/usr/bin/env python
import os
import sys

env = SConscript("../godot-cpp/SConstruct")

# For reference:
# - CCFLAGS are compilation flags shared between C and C++
# - CFLAGS are for C-specific compilation flags
# - CXXFLAGS are for C++-specific compilation flags
# - CPPFLAGS are for pre-processor flags
# - CPPDEFINES are for pre-processor defines
# - LINKFLAGS are for linking flags

# tweak this if you want to use different folders, or more folders, to store your source code in.
env.Append(CPPPATH=["src/"])
sources = Glob("src/*.cpp")

if env["platform"] == "windows":
    library = env.SharedLibrary(
        "bin/mylib{}{}".format(env["suffix"], env["SHLIBSUFFIX"]),
        source=sources,
        LIBS=["<library>", f"godot-cpp{env["suffix"]}"],
        LIBPATH=["<path_to_library>", "../godot-cpp/bin"],
    )
else:
    library = env.SharedLibrary(
        "bin/mylib{}{}".format(env["suffix"], env["SHLIBSUFFIX"]),
        source=sources,
        LIBS=["<library>", f"godot-cpp{env["suffix"]}"],
        LIBPATH=["<path_to_library>", "../godot-cpp/bin"],
    )

Default(library)

Steps to reproduce

Build for windows: scons platform=windows debug_symbols=yes

build for linux: cons platform=linux debug_symbols=yes

Minimal reproduction project

N/A

[dsnopek]

With verbose output I found out, that when building for windows, it wants to build a statically by default (use_static_cpp=true), while building for linux is shared by default (use_static_cpp=false).

The use_static_cpp=yes isn't about building your library statically, it's about statically linking against the C++ runtime library.

Most Linux systems have this installed in a global location already, so it's not necessary to statically link against it. (Although, statically linking can help with differences between Linux distributions and versions.) However, most Windows systems do not - applications either ship the shared library with their app, or statically link against it.

Can you share the actual error message? I wouldn't expect this option to cause any problems

[Nanowires]

When building for windows, without the use_static_cpp=true:

x86_64-w64-mingw32-g++ -o src/gdmylib.os -c -std=c++17 -fno-exceptions -Wwrite-strings -fvisibility=hidden -gdwarf-4 -g2 -O2 -fPIC -DWINDOWS_ENABLED -DTHREADS_ENABLED -DHOT_RELOAD_ENABLED -DDEBUG_ENABLED -DDEBUG_METHODS_ENABLED -DNDEBUG -DGDEXTENSION -I<path>/godot-cpp/gdextension -I<path>/godot-cpp/include -I<path>/godot-cpp/gen/include -Isrc src/gdmylib.cpp
x86_64-w64-mingw32-g++ -o src/gdplotVector.os -c -std=c++17 -fno-exceptions -Wwrite-strings -fvisibility=hidden -gdwarf-4 -g2 -O2 -fPIC -DWINDOWS_ENABLED -DTHREADS_ENABLED -DHOT_RELOAD_ENABLED -DDEBUG_ENABLED -DDEBUG_METHODS_ENABLED -DNDEBUG -DGDEXTENSION -I<path>/godot-cpp/gdextension -I<path>/godot-cpp/include -I<path>/godot-cpp/gen/include -Isrc src/gdplotVector.cpp
x86_64-w64-mingw32-g++ -o src/mylib.os -c -std=c++17 -fno-exceptions -Wwrite-strings -fvisibility=hidden -gdwarf-4 -g2 -O2 -fPIC -DWINDOWS_ENABLED -DTHREADS_ENABLED -DHOT_RELOAD_ENABLED -DDEBUG_ENABLED -DDEBUG_METHODS_ENABLED -DNDEBUG -DGDEXTENSION -I<path>/godot-cpp/gdextension -I<path>/godot-cpp/include -I<path>/godot-cpp/gen/include -Isrc src/mylib.cpp
x86_64-w64-mingw32-g++ -o src/register_types.os -c -std=c++17 -fno-exceptions -Wwrite-strings -fvisibility=hidden -gdwarf-4 -g2 -O2 -fPIC -DWINDOWS_ENABLED -DTHREADS_ENABLED -DHOT_RELOAD_ENABLED -DDEBUG_ENABLED -DDEBUG_METHODS_ENABLED -DNDEBUG -DGDEXTENSION -I<path>/godot-cpp/gdextension -I<path>/godot-cpp/include -I<path>/godot-cpp/gen/include -Isrc src/register_types.cpp
x86_64-w64-mingw32-g++ -o bin/libgdsimwrapper.windows.template_debug.x86_64.dll -Wl,--no-undefined -static -static-libgcc -static-libstdc++ -fvisibility=hidden -shared src/gdmylib.os src/gdplotVector.os src/mylib.os src/register_types.os -L<path>/mylib-tmp/build_win_64/lib -L<path>/godot-cpp/bin -lmylib -lgodot-cpp.windows.template_debug.x86_64
/usr/lib/gcc/x86_64-w64-mingw32/14.2.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmylib: No such file or directory
collect2: error: ld returned 1 exit status
scons: *** [bin/libgdsimwrapper.windows.template_debug.x86_64.dll] Error 1
scons: building terminated because of errors.

When adding the use_static_cpp=true, it compiles without errors.

I guess is, that when using the use_static_cpp=true option, it will not only link statically against the c++ runtime library, but also any 3rd party library, that the extension is depending on. But that's the problem here, as I cannot build a static dll of mylib

[dsnopek]

Ah, perhaps the -static shouldn't be in there, and only the -static-libgcc -static-libstdc++?

I think we inherited the -static from Godot's build system, but perhaps it's used there to ensure that libraries are used from thirdparty/ and not a shared library installed on the system? If that's the case, then we don't need it always in godot-cpp, and can remove it