Reputation: 1369
I have a small game that I want to distribute, but I want to ship it with all the needed shared libraries so that users don't have any dependencies to install.
This is the output of ldd:
linux-vdso.so.1 (0x00007fff311c4000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fcca3449000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fcca3245000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007fcca2fba000)
libGLEW.so.2.1 => /usr/lib/libGLEW.so.2.1 (0x00007fcca2d12000)
libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007fcca29f6000)
libSDL2_image-2.0.so.0 => /usr/lib/libSDL2_image-2.0.so.0 (0x00007fcca27d3000)
libSDL2_ttf-2.0.so.0 => /usr/lib/libSDL2_ttf-2.0.so.0 (0x00007fcca25cb000)
libSDL2_mixer-2.0.so.0 => /usr/lib/libSDL2_mixer-2.0.so.0 (0x00007fcca237c000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fcca215e000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fcca1da7000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fcca3a68000)
libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007fcca1b75000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fcca1836000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fcca1624000)
libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007fcca136e000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fcca1166000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007fcca0ea0000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fcca0c77000)
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007fcca0a67000)
libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007fcca0830000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007fcca0619000)
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007fcca0380000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fcca017c000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fcc9ff76000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fcc9fc63000)
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007fcc9fa37000)
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fcc9f7c4000)
How do I know which ones come by default on any linux distro and which ones should I ship with my game?
Upvotes: 0
Views: 312
Reputation: 4307
There's a reason why it is so common to distribute Linux/Unix applications as source code, and not binaries -- it's very hard to distribute binaries that will work in a wide range of platforms. It's the same reason that distribution-specific software repositories are such a feature of Linux life.
The problem is that, although the libraries you list will be generally available, their versions will differ from distribution to distribution. And that's to ignore the really fundamental problem that Linux runs on a various CPUs and hardware architectures.
If your program is likely to be of general interest, the easiest way (technically, at least) to deal with supply is to make the source code available, e.g., on github, and convince distribution maintainers to build it for their distributions. Distro maintainers have automated ways of doing this kind of thing.
If you can't do that, then I would suggest that you might need to distribute with your executable everything except the standard C libraries and platform libraries. That is, you can assume compatibility in the C libraries, libdm, libpthread, and libm; everything else you'll need to supply. You can supply the libraries as separate files, along with some sort of script or wrapper that sets LD_LIBRARY_PATH to make them available, or just link them into the executable. Frankly, there could be incompatibilities even in the platform libraries if the host system is very much older or newer than the build system.
Or you can have your application load libraries at runtime, and have some sort of logic that attempts to find the appropriate ones in the host system. And, presumably, checks for compatibility. This is what the Java JVMs typically do.
What won't work very well is to build your application on one Linux distribution, and just hope it will work on others. Unfortunately.
Upvotes: 1