On building portable Linux binaries

I've always thought it would be interesting to have a statically linked executable that was actually statically linked to externally-visible, signed copies of shared libs that are embedded in themselves, so that the dynamic linker could recognize when two processes, both of which are statically linked, could still share the same pages in memory because they have both statically linked the same lib+version. In other words, you get the memory and io savings of dynamic libs, but you get none of the dependency resolution problems (and none of the disk space savings).

You can use Gentoo Prefix for this:<p><a href="https://www.gentoo.org/proj/en/gentoo-alt/prefix/" rel="nofollow">https:&#x2F;&#x2F;www.gentoo.org&#x2F;proj&#x2F;en&#x2F;gentoo-alt&#x2F;prefix&#x2F;</a><p>It builds everyting except libc. Support for building libc is under development by the project. I used an early version of it to provide a build environment for the ZFSOnLinux kernel modules on CoreOS:<p><a href="https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos-tutorial-667/docs/experimental/zfs-on-coreos.rst" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ClusterHQ&#x2F;flocker&#x2F;blob&#x2F;zfs-on-coreos-tuto...</a>

Another option:<p>Most&#x2F;all modern distributions can run programs built with lsbcc[1] from the Linux Standard Base workgroup. The lsbdev environment links your program against &quot;stub&quot; .so files that advertise appropriate symbol versions, and prevent referencing library symbols that are not defined in the standard.<p>It can be somewhat of a hassle to get programs to build in this environment, but it greatly reduces the chances of finding an incompatibility when the program is later run under an unexpected Linux distribution. LSB includes an app checker[2] which can generate reports[3] showing compatibility with various distributions.<p>[1] <a href="https://wiki.linuxfoundation.org/en/Book/HowToDevel" rel="nofollow">https:&#x2F;&#x2F;wiki.linuxfoundation.org&#x2F;en&#x2F;Book&#x2F;HowToDevel</a><p>[2] <a href="http://ispras.linuxbase.org/index.php/About_Linux_Application_Checker" rel="nofollow">http:&#x2F;&#x2F;ispras.linuxbase.org&#x2F;index.php&#x2F;About_Linux_Applicatio...</a><p>[3] <a href="http://ispras.linuxbase.org/index.php/File:LAC_TestReportDist.png" rel="nofollow">http:&#x2F;&#x2F;ispras.linuxbase.org&#x2F;index.php&#x2F;File:LAC_TestReportDis...</a>

By far the most reliable way I&#x27;ve found to run old binaries on Linux is ... to run a Windows binary under Wine.<p>We have the portable all-free-software binary handler, yay! It just has Win32 in the middle ...

I know it&#x27;s not a panacea, but the Open Build Service is helpful in building packages for multiple distributions.

I recently started using Fedora, love it, hate the lack of software. I could always contribute to packaging software not yet available, like e.g. Atom, but in the time I could waste learning to do these things I could of installed Ubuntu. I&#x27;ll keep it for now, though. Maybe I&#x27;ll figure out how to package and somehow release some lovely RPM&#x27;s. I love Fedora, hate the lack of packages.

A made a tool called Whack [1] as an attempt to solve a small part of the problem. The idea was that you could write scripts that would build statically-linked versions of binaries, such as Apache HTTPD [2]. Then, you could run a command like:<p><pre><code> whack install git+https:&#x2F;&#x2F;github.com&#x2F;mwilliamson&#x2F;whack-package-apache2-mod-php5 apps&#x2F;apache2 </code></pre> to install to any location you wanted, and the installation would still work if you mv&#x27;d the entire directory somewhere else, or even onto another distribution (provided it didn&#x27;t have an older libc).<p>I never really the pushed the idea further since I think doing a decent job requires a lot of time and effort, and it solves something which is a minor annoyance for me, rather than causing significant pain. I do still use it for when I need to quickly get a WordPress server for development up and running since it&#x27;s one command to deploy from scratch.<p>It feels to me like there&#x27;s lots of scope for something similar to apt-get that builds and installs static binaries (or, at the very least, lets you install to different directories without root, similar to, say, virtualenv for Python or RVM for Ruby).<p>EDIT: actually, from a quick glance, it seems like Gentoo Prefix [3], as mentioned by ryao, allows you to install things as you normally would on a Gentoo machine, but without being root and with a prefix of your choosing.<p>[1] <a href="https://github.com/mwilliamson/whack" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mwilliamson&#x2F;whack</a> [2] <a href="https://github.com/mwilliamson/whack-package-apache2-mod-php5" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mwilliamson&#x2F;whack-package-apache2-mod-php...</a> [3] <a href="https://www.gentoo.org/proj/en/gentoo-alt/prefix/" rel="nofollow">https:&#x2F;&#x2F;www.gentoo.org&#x2F;proj&#x2F;en&#x2F;gentoo-alt&#x2F;prefix&#x2F;</a>

It&#x27;s sad that this is still a problem. Every time it comes up the old &quot;just open source it&quot;, &quot;just dynamically link everything&quot;, &quot;just make a package for every distribution and version of libc&quot; people come out and stop and sort of progress.<p>Autopackage gave up because of this lack of progress.<p>So we are left with two equally awful &quot;solutions&quot;:<p>1. Do all your development on years-old linux distros. 2. Use docker and essentially package an entire distro with your app.<p>This is never a problem on Windows.