Portable .so library for Linux

Question

I am writing a Python app that works with graphics and depends on PySDL2 library. PySDL2 depends on compiled SDL2 binary library that can be downloaded from SDL site. I wrote a bootstrap script to automate the process, but it works only for Windows, because there is no binary download for Linux.

The question is how to make that binary SDL2 download for Linux?

It is not clear if it is possible to create .so file that will work on every Linux at all, if it is because it is impossible to create .so file that will work on every CPU, and that's mostly because it is not clear if any work was already done in this direction (I am sure people tried to research this problem) and if it is, then why the format of portable .so file (cross-platform against different distributions and CPUs) was not adopted.

UPDATE: I don't mind installing dependencies (packages) with updates and security fixes provided by Linux community, but this should be done in user space, and I need the ability to automate it with portable scripts.

Answer 1

Don't do this.

The most reliable way would be to make a complete static built library stack.

But this will totally bloat your application and if there ever is any security issue in these libraries, you will need to update this yourself and all your users will need to re-download.

By using the distribution provided SDL libraries, your application will benefit from SDL bugfixes and updates done by the Linux community.

Consider providing packages for the most common distributions (i.e. Debian, Ubuntu, Redhat, Fedora) that then have proper dependencies on the distribution-provided SDL library.

When you look at how Skype, Google etc. distribute their binaries, it's always in a distribution-specific package, that can then work with the system libraries. For example Skype:

Depends: libasound2 (>= 1.0.16), libc6 (>= 2.3.6-6~), libc6 (>= 2.7),
  libgcc1 (>= 1:4.1.1), libqt4-dbus (>= 4:4.5.3), libqt4-network (>= 4:4.8.0),
  libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.8.0),
  libqtwebkit4 (>= 2.1.0~2011week13), libstdc++6 (>= 4.6), libx11-6, libxext6,
  libxss1, libxv1, libssl1.0.0

As you can see, skype does not bring all its libraries included. When installing Skype, the user may have to rely on his package manager to resolve these dependencies.

Furthermore, Linux users are very reluctant to download or install binaries at all. If you really want people to use your "app", you better make it open source and have someone include it with the major Linux distributions. Linux isn't Windows. One of the reasons there are few viruses on Linux is because most people don't download untrusted software.

Answer 2

Regarding CPU architectures, Linux does not have support for Fat Binaries (more than architecture per binary, something which is available in OS X for example). There was a proposal called Fat ELF by Ryan Gordon which sadly didn't go anywhere.

In the particular case of SDL2, the library links by default to very few libraries:

ldd /usr/local/lib/libSDL2.so

    linux-vdso.so.1 =>  (0x00007fffd1f0b000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f414c44e000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f414c24a000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f414c02c000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f414be24000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f414ba5c000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f414cac4000)

The rest of the binaries SDL depends on are loaded dynamically (using dlopen), and SDL is quite adaptable to different versions of certain binaries. So, in short, if you compile in a system with certain versions of libc, libpthread, etc and manage to find a different system with compatible binaries, you have a good chance that the SDL binary will at least run. In practice, you are better off depending on the system provided binary, or accept that you'll be supporting a limited set of distros with your custom made SDL2.

Note that this limitation also applies if you link SDL statically! And if you think you can keep on adding statically linked binaries until you've made a static ball of several hundred megs that runs anywhere (like I did!), there's other limitations that prevent you from doing that, ranging from licensing issues to segfaults due to linking libpthread statically.