在 Linux 上分发纯二进制软件时，我不应该包含哪些共享库？

Question

The usual recommendation for handling the dependencies on Linux is by using the distro's package manager.

The good part of this approach is that you can reuse the basic set of libraries configured, tested, and updated for your system.

The bad part is that there are many distros with different package managers, and you probably have to support several of them. Users of not-so-popular distros have to work on their own to set up the dependencies.

The worst part is, when talking about games, some game distribution platforms ban the developer from using package files for installation.

Quotingitch.io ,

.deb and .rpm packages (Oh no tier)

These are ignored when looking for uploads - it'll appear as if your app wasn't available on Linux at all.

Do not use these.

To not use the package manager, one way is to build the app on a reasonably old system, like Debian oldstable or the Steam Runtime (based on Ubuntu 12.04), and distribute the final software by copying the shared libraries depended upon.

My question is which shared libraries should be copy-distributed in this stage.

Do I have to ship libc? If I don't, is it guaranteed that newer versions of libc has backwards compatibility with older versions of libc?

Can I just be safe and ship all the dependencies? Will it work on most systems despite being a bit heavy?

If that's not a solution, which shared libraries should I include and which not?

Answer 1

Do I have to ship libc?

For reasons explained here , it is nearly guaranteed that your libc.so.6 will not be compatible with the system ld-linux.so (the path to system ld-linux.so is baked into your binary).

You could however use a shell wrapper to avoid this problem. Something along the lines of:

#!/bin/bash
TOP=/path/to/your/install
exec -a "mygame" "$TOP/lib64/ld-linux-x86-64.so.2" --library-path "$TOP/lib64" "$TOP/bin/mygame" 

If I don't, is it guaranteed that newer versions of libc has backwards compatibility with older versions of libc?

Yes, GLIBC backward compatibility guarantees exactly that: you could copy a binary from a system of 10 or 20 years ago, and it will run on a freshly installed latest distribution ¹ .

which shared libraries should I include and which not?

Note that by distributing GPL software you assume certain obligations. Talk to your lawyer if you plan to do that.

---

¹ There have been a few bugs about 15 years ago where this backward compatibility was broken in some specific cases, but you are unlikely to run into them.