Allow linking MSVC runtime dynamically

[ghuser404]

Describe the project you are working on

An app using Godot Engine.

Describe the problem or limitation you are having in your project

When exporting the app using the build templates, the executable size ends up very large. If I understand correctly, it's because it link MSVC runtime statically.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I'm not very sure why static runtime linkage is default, because statically linked apps have potential vulenrability issues, because they don't receive updates when the runtime receives security updates. Most of the apps link to the runtime dynamically, and whenever the runtime is updated via a Windows update or whatever, they get to use the updated runtime automatically. So IMO, dynamic linkage would preferably be the default option.
Also, this makes output executable smaller in size, which is a big plus also.

I think Godot should provide an option to build the executable with dynamic runtime linkage. AFAIK, there is no such option, at least I didn't find one.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

When exporting the app, user would be able to tick a box for static/dynamic runtime linkage.

If this enhancement will not be used often, can it be worked around with a few lines of script?

N/A

Is there a reason why this should be core and not an add-on in the asset library?

N/A

[Calinou]

• Related to Add a SCons option to compile modules as shared libraries for faster rebuilds #1796.

Godot does not depend on the VC++ redistributable, so I don't think there are any savings possible here. Official export templates are compiled using MinGW too, so they can't even depend on the VC++ redistributable. When using MinGW, its C++ runtime is always statically linked as there is no system-wide MinGW runtime available.

Using MinGW is preferred for production binaries as the GDScript VM performs a lot better with it compared to MSVC.

When exporting the app, user would be able to tick a box for static/dynamic runtime linkage.

It's not possible to switch between static and dynamic linking of a runtime or library without recompiling the binary, so this wouldn't be feasible on export either way.

[bruvzg]

If you are building a custom export template, you can do it by adding use_static_cpp=no to the build flags (works with both MinGW and MSVC).

Since official templates are built with MinGW, and MinGW runtime is not available in as part of default Windows install (you'll need all DLLs in the same folder), it's definitely not a preferred default.

[ghuser404]

Thank you for the explanation.

Using MinGW is preferred for production binaries as the GDScript VM performs a lot better with it compared to MSVC.

@Calinou If one wants to use purely GDExtension (godot-cpp) without using GDScript, would it make sense to compile the templates with MSVC? Or is the VM still being used somehow, even if user's code doesn't use GDScripts?

@bruvzg Makes sense. Just an observation, I noticed that godot for MinGW passes -static -static-libgcc -static-libstdc++ for 32-bit and only -static for 64-bit; but godot-cpp passes -static -static-libgcc -static-libstdc++ regardless of the bitness. Do you think these should be aligned?