I'm currently using the Allegro PPA on Ubuntu to build my engine on Linux. I found out from a tester, however, that this causes Allegro to be linked dynamically and fails with a dependency error on any system without the Allegro libs installed.

For my Windows releases I static link all dependencies, so that the engine is self-contained in a single .exe file. How would I go about doing the same for Linux?

Be sure to specify static libraries when you make Allegro.

mkdir build
cd build
cmake -DSHARED=off ..
make
sudo make install

Then when you compile your program, use the static libraries (allegro-static-5, allegro_primitives-static-5, etc). If you're using pkg-config, be sure to use "--static", like $(pkg-config --libs --static allegro-static-5), for example.

I've never used Allegro from a PPA. Does it include the source code, or just pre-built binaries?

I don't really mind having a dynamic dependency on principle, but I also don't want to have to force all my users to have to drop to the commandline themselves to get the needed Allegro libs. Guess I'll have to look into creating a package myself.

It doesn't seem like a problem in practice. From what I understand, the totality of a repository advances in lockstep. Static linking prevents efficient security updates, but I can understand how security isn't something that comes first to mind when you're using Windows .

Funny how I've only had one virus in like 20 years. All you need is a good firewall and the sense not to download shady programs. Real time anti-virus is nice too, but I've never really needed it. :/

I think the best distribution method is to distribute packages. This would typically not be statically linked, and would utilize the packages in the target distribution's repository. With the PPA, for Ubuntu/derivatives you could create a package that would depend on the PPA and it'll fetch all the dependencies automatically. You might think this is crazy, but it works just fine in practice. If you tried to submit a statically linked package to the standard repositories, it would be rejected.

If you don't want to make a package (it is a pain, in practice), you can do one of two things, depending how paranoid you are about your dependencies.

First you can statically link OR include the shared libraries of the dependencies that are not in the target distribution's repository, and rely on the packages for the rest. That's what I do typically.

If you're paranoid about your dependencies changing, nothing stops you from including them all except for the fact that there are TONS of them. Consider the shared libraries linked to by my game:

      linux-vdso.so.1 =>  (0x00007ffe725b8000)
        libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f3e44ed8000)
        libdumb.so.1 => /usr/lib/x86_64-linux-gnu/libdumb.so.1 (0x00007f3e44ca0000)
        libvorbisfile.so.3 => /usr/lib/x86_64-linux-gnu/libvorbisfile.so.3 (0x00007f3e44a98000)
        libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f3e44890000)
        libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f3e44640000)
        libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f3e44350000)
        libopenal.so.1 => /usr/lib/x86_64-linux-gnu/libopenal.so.1 (0x00007f3e440f0000)
        libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f3e43ec8000)
        libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f3e43c70000)
        libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f3e43630000)
        libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007f3e43378000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f3e43150000)
        libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f3e42ef8000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f3e42bf0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3e428e8000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3e426c8000)
        libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f3e424b8000)
        libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f3e422a8000)
        libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f3e420a0000)
        libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f3e41e90000)
        libGL.so.1 => /usr/lib/fglrx/libGL.so.1 (0x00007f3e41c90000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f3e41958000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3e41750000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3e41388000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3e454f8000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3e41180000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3e40f68000)
        libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f3e40d58000)
        libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f3e40b28000)
        libpulsecommon-4.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-4.0.so (0x00007f3e408c0000)
        libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2 (0x00007f3e406b0000)
        libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f3e40468000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3e40248000)
        libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f3e40040000)
        libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f3e3fe30000)
        libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f3e3fc28000)
        libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f3e3fa00000)
        libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f3e3f6f0000)
        libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f3e3f378000)
        libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f3e3f160000)
        libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f3e3ef10000)
        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f3e3ecd0000)
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f3e3eac0000)
        libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f3e3e8b8000)
        libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f3e3e6b0000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f3e3e498000)
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f3e3e290000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f3e3e050000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f3e3de30000)
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f3e3dc20000)
        libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f3e3d9b8000)
        libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f3e3d7b0000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f3e3d4f0000)
        libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f3e3d240000)
        libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f3e3d038000)
        libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f3e3ce28000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f3e3cc00000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3e3c9e0000)
        libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f3e3c788000)
        libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f3e3c578000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f3e3c348000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f3e3c140000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f3e3bf38000)
        libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3e3bd18000)
        libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f3e3b848000)
        libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f3e3b628000)
        libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f3e3b420000)

Almost all of those will have to be included depending on your level of paranoia. I think you'd be crazy to statically link them, and what commercial projects without packages typically do is bundle the dynamic libraries they're not sure about.

But at that point, I'm not sure what the motivation is. The package system is the best thing about using Linux, why make your life difficult by ignoring its existence?

I think the difficulty is a little overblown. I've been making Linux binaries for awhile and it's very rare to have them not work. The typical issue is that the C runtime library is not up to date on the target system, so what I used to do is compile things on an older Debian. Since the runtime is backwards compatible, these binaries would work fine in modern distributions. In principle you can just stick everything in a tar.gz and have it just work. It's not 'proper', but plenty of 'serious' projects do that.

Ubuntu is switching from apt to their Ubuntu Snappy, which means... every package comes with all dependencies and shared libraries bundled and nothing will get installed outside an app's folder anymore - so basically very soon Linux packaging will be like windows and osx