2

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?

xiver77
  • 2,162
  • 1
  • 2
  • 12

1 Answers1

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 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
  • 199,314
  • 34
  • 295
  • 362
  • I'd rather not ship libc if that's possible. What I meant by newer versions of libc having backwards compatibility, is that whether a program linked to an older version of the *shared* system libc will run fine on a system with a newer version of libc, Of course, the libc will be the same kind, most likely glibc. – xiver77 Jul 13 '22 at 05:49
  • @xiver77 Yes, GLIBC is backwards compatible, and the program linked against an older GLIBC will run fine on a system with newer GLIBC. – Employed Russian Jul 13 '22 at 12:48
  • When I run `ldd` on system `.so` files, it seems that most (all?) of them are linked to `/lib64/ld-linux-x86-64.so.2` with an absolute address. Does that mean all of these shared libraries will have a compatibility problem when run on a different system with a different `ld-linux.so`? – xiver77 Jul 14 '22 at 12:44
  • @xiver77 Yes: every shared library depends on `libc.so.6` and `ld-linux...`. They will all work (due to backward compatibility) if target system GLIBC is newer the build system GLIBC. They could fail if target GLIBC is older than build system GLIBC. – Employed Russian Jul 14 '22 at 15:44
  • Thanks for answering. I need time to digest the things you've written, but there are other problems to deal with right now. I'll come back to this later. – xiver77 Jul 15 '22 at 12:39