[Ohrrpgce] linux nightly builds plans

[Ralph Versteegen]

On 23 February 2017 at 07:15, James Paige <Bob at hamsterrepublic.com> wrote:

> So making a binary that works across multiple Linux distributions is
> apparently way harder than I previously assumed.
>
> Our linux nightlies are build on Debian Jessie
>
> 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.
>
> 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.
>

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?).

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

I'll use objdump to inspect those nightly builds and see what library
versions they depend on.


> 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.
>

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:
1) ancient RHEL and other systems from ~2005 which had some incompatible
build options
2) ancient binaries from ~2003 on a modern system which use a libc which
modern distros no longer include by default
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

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.

I'm currently building a crosscompiling toolchain using crosstools-ng with
glibc 2.12.2 (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 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170223/e0bf5154/attachment.htm>