<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2017 at 07:15, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>So making a binary that works across multiple Linux distributions is apparently way harder than I previously assumed.<br><br></div>Our linux nightlies are build on Debian Jessie<br><br></div>These binaries definitely don't work on either Ubuntu 14.04 or  Ubuntu 16.04, and I suspect they have problems on other Ubuntus, but I don't know which ones.<br><br></div>I know that our Debian Jessie nightlies DO work on Steam (or at least they did last time I checked), even on Ubuntu 14.04, and I think that is simply because Steam itself takes care of providing copies of the necessary versions of libc.<br></div></div></blockquote><div><br></div><div>Yes, Steam includes a copy of the Ubuntu system libraries. Apparently the latest version, if your binaries works there, though it used to be 14.04 (or 14.10?).<br><br></div><div>If the builds don't work on 16.04 then they're not going to work on any older Ubuntu either, unless the only problem is libtinfo.so getting split from libncurses.so<br></div><div><br></div><div>I'll use objdump to inspect those nightly builds and see what library versions they depend on.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div>Right now I am thinking of the possibility of distributing multiple Linux binaries for different distros. I think doing this via a few VMs would probably be reasonable-- and certainly easier than figuring out cross-distro cross-compiling.<br></div></blockquote><div><br></div><div>It is possible that a binary compiled on system A doesn't work on system B, and a binary compiled on B doesn't work on A. However so far I have only heard of a few cases where that happens:<br></div><div>1) ancient RHEL and other systems from ~2005 which had some incompatible build options<br></div><div>2) ancient binaries from ~2003 on a modern system which use a libc which modern distros no longer include by default <br></div></div>3) two systems with similar versions of system libraries, e.g one has a newer libc and the other a newer libstdc++, so neither is strictly more recent than the other<br><br></div><div class="gmail_extra">Aside from those I can't see why it would be necessary to provide binaries for multiple distros; I would expect the binaries for the oldest of those to work on all the others too, provided that it doesn't link to libtinfo.so.<br><br></div><div class="gmail_extra">I'm currently building a crosscompiling toolchain using crosstools-ng with glibc 2.12.2 (<span class="gmail-st">2010-12-13), which is the oldest it supports. However the oldest gcc it supports (even if you enable obsolete features) is gcc 4.8.5, which uses a libstdc++.so only 100% backcompat as far back as gcc 4.8.3, which was released </span>2014-05-22. (Unlike glibc, libstdc++ is tied to a particular g++ version). However, that's worst case; if we don't actually use any of the new features introduced in gcc 4.8.3 then it will work with an older libstdc++.so. We have very little C++ code and it uses almost none of the C++ standard library, so I would assume we'll be alright. Worst case, we can link libstdc++ statically or include the .so in the package, or I'll just have to use a previous version of crosstools-ng. I started adding info about this to the Portable Linux Binaries wiki page. <br><br></div><div class="gmail_extra">We can make SConscript check with objdump that we aren't accidentally depending on a recent libc or libstdc++. I think ~2011 is a good target. It would be nice to have a gcc as recent as possible though.<br></div></div>