| 1 - vulkan godot backend is not mature yet. 2 - On glibc/linux target: it should generate pure and simple ELF binaries (not C/c++ binaries). It has the following implications: a - the static libstdc++ from gcc probably has to be forked that to "libdl" everything it needs from the glibc/posix libs. b - everything else from the system has to be libdl-ed too, even the libc symbols. c - third party libs must be libdl-ized too. d - ofc, usage of "-static-libgcc" and "-static-libstdc++" build options to mitigate ABI issues (got hit again by that and recently, c++ ABI nightmare). e - no C/c++ main() function, only the sysv ABI(ELF) entry point (which is basically main anyway). f - usage of system TLS variable, like errno, must be handled only via the sysv ABI __tls_get_addr() ABI function (I have to admit, I did not dive that much into this issue yet). g - proton is a money sink hole, massive and horrible software microsoft grade. To make it worse, it is said to include actual real software components from doz. Only consider it if your technical debt on doz OSes is too high (basically, you started to "think" "other platform ports" too late). If not mitigating those issues above: games using godot must be build on the oldest glibc as possible, that to avoid GNU symbol versioning issues. They should static link as much as the can, even some glibc libs (libm static linking is mandatory since GNU symbol versions here are madness). And conservatively build using the "-static-libgcc" "-static-libstdc++" options. rant on: Godot should not have been a c++ engine but a simple C/ASM one (should be able to compile with tcc/cproc/scc/pcc/etc), using the preprocessor for namespaces in order to avoid symbol collision, and using compile-time function tables and runtime function tables (for "fallbacks", like wayland->x11). The really guilty ppl are actually glibc and gcc devs, not the game devs.
rant off. |