在 Linux 上分发一个 C++ 应用程序（游戏）：共享或 static 库？

Question

I have a C++ game/application which use several libraries: OpenGL, OpenAL, Curl, Freetype2, GLFW, etc. Should I distribute my C++ binary application on Linux using the shared libraries or should I link them statically?

• Static libraries : it seems a good solution to have my application working on most of the Linux distributions. Indeed, my application won't depend on libraries version installed on the system. Unfortunately, it seems quite painful to perform this static link because most of libraries don't provide a static library file (*.a) by default. Therefore, I have the felling that it isn't a common pratice. However, I checked several games distributed by GOG.com and all games I checked don't depend of shared libraries (checked with lddtree )
• Shared libraries : it seems to be the recommended solution but it seems almost impossible that my C++ application will be compatible with all Linux distributions. I should build a binary specific for Ubuntu 16.04, then build another binary for Ubuntu 20.04, etc... That seems very time consuming for a single developper.

Did I miss something? Note: on Windows, it is more simple: I can use shared libraries (*.dll) and provide them with my application. On Linux, it seems quite difficult to provie the shared libraries. Example: "libcurl-gnutls.so.4" depends of > 20 others shared libraries: it is not the case on Windows with "libcurl-x64.dll" which is self sufficient.

Answer 1

I finally answer myself to my question after analyzed dozens of video games more. There are mainly two categories:

1. Games built with only static libraries. Most of the time, it seems related to games using Unreal Engine.

2. Games built with shared libraries which are delivered with the game. The game starts via a bash script and use LD_LIBRARY_PATH to define the path to these shared libraries. Seems the best solution for me even if it is not the spirit of the shared libraries.

Side notes:

• Game distributed through packages (RPM, DEB, etc..) for the main versions of the Linux distributions exist but are quite rare.
• There are also games using dynamic libraries which are not distributed with the game but only 60% of these game are able to start on my Linux distribution !
• I haven't seen game using Snap / Flatpak / AppImage.

Answer 2

I don't see a reason why your C++ shared library would necessarily be incompatible with different Ubutu releases, or why it would need to resort to LD_LIBRARY_PATH. Different releases (version numbers) of a shared library can co-exist in the system, and the program loader is able to search for the correct version based on ELF metadata annotated in the binary. Moreover, GNU/Linux shared objects are equivalent to Windows DLLs for this purpose. If your code is portable, you may even use MinGW to build both.so and.dll objects from the same source file (GNU build system, aka Autotools may be of great help).