Which shared libraries should I not include when distributing binary-only software on Linux?

user_17665807 0
Viewed 59

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.

Quoting itch.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?

libc dependencies shared-libraries linux c
1 Answers

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 distribution1.

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.

1There 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.

Employed_Russian_506170
Related