logoalt Hacker News

sylware • today at 11:22 AM • 0 replies • view on HN

c++ is sorta private to the application.

If the API is c++ based you have to statically link it to the engine since the chosen c++ runtime is statically linked to the engine binaries.

You cannot ship as a shared c++ runtime since it would conflict with a possible version installed on the user distro (version of the gcc libstdc++, version of the clang runtime, intel?, or none see below).

To avoid c++ ABI issues, distros may statically link their c++ runtimes (clang[c++ and compiler versions]/gcc[c++ and compiler and versions]/intel[c++ and compiler versions]/etc)... if they need any (and the new c++ to C transpiler may have some significant impact in the near future).

(BTW, is the c++ intel compiler still shipping??)

If the API is "C" based (aka core platform ABI), no issue, just statically load only the common glibc libs (ELF DT_NEED entries) and dynamically load (libdl/dlopen/dlsym/dlclose) everything else (private libs, or system interface shared libs), and you are good to ship. A word though: wayland code with its libxkbcommon are statically linked, do not reproduce the same mistakes than with x11).

This is required for broad distro support [and long term support].

Basically, game binaries should be "-static-libgcc -static-libstdc++ --enable-new-dtags" everywhere, statically load _ONLY_ common glibc libs (and with "old" symbol versions, see binutils ld documentation, the 2nd part of the VERSION documentation page), and dynamically load everything else.

I have been inspecting many recent godot4 games on steam: all had "correct" binaries to maximize broad distro loading support on the long run.

The current issues: some games are written in microsoft rust which toolchain is still unable to statically link libgcc (see tinyglade game). Or some unity versions which "forgot" the '-static-libgcc' compiling/linking options, and even forgot to statically link their libz Oo.

If valve could do just that with the binaries of their client and their games... They can keep their 'runtimes' for old broken games but should have 'correct' binaries for everything else on their side (and valve still has to port the final 32bits reaper command to 64bits for clean 64bits support, hopefully I did not miss other 32bits binaries). Forcing distros to compile that user namespace in their linux kernel is quite "inappropriate", better keep that optional for those broken games only.