[Ohrrpgce] linux nightly builds plans

[Ralph Versteegen]

On 23 February 2017 at 17:30, Ralph Versteegen <teeemcee at gmail.com> wrote:

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

This was far too optimistic I think; there are lots of libraries which
occasionally break their ABIs, and not every distro is going to keep around
the old versions for very long. Actually it seems to be the norm to not
keep around old versions, except for a few of the most critical libraries
like libc, libncurses. Some libraries like libssl are notorious for
frequent ABI changes. We don't depend on much, luckily. I don't know if
ogg, vorbis or


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

OK, the reason that the nightly builds don't work on older machines is,
firstly, because they depend on CXXABI_1.3.8 (which is GCC 4.9), in
particular the symbol __cxa_throw_bad_array_new_length@@CXXABI_1.3.8

As you can see from
http://packages.ubuntu.com/search?keywords=libstdc%2B%2B6
Ubuntu 16.04 has GCC 5.4.0, while 14.04 had 4.8.4. So this doesn't explain
why 16.04 doesn't work.

I managed to get rid of that symbol easily.

Next, I found I got the error "libncurses.so.6 not found" on Ubuntu 14.04.
I fixed that by linking against libncurses.so.5 instead. You can now do so
by running "scons portable=1". (Maybe you will have to install the dev
package for that version?) That's enough to get the builds to work on my
ubuntu 14.04 netbook. I don't think that's the end of it, but hopefully we
can keep working through the problems like this.
But come to think of it, libfb.a ought to be built against libcurses.so.5,
otherwise linking against the newer version with a different ABI might
cause a crash. But libfb only uses 2-3 functions from the libtinfo subset
of ncurses, and I'm almost certain those wouldn't have changed in signature
(because it would have changed the API unless they're macros)

I couldn't manage to get that cross-compiler to build; it kept failing half
an hour into the build. It would build if I took one of the templates
without modifying anything (took 57 min in total to build!) But in that
case the cross compiler is pretty useless. I'll probably give up on it if
it's not needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170224/e3616034/attachment-0001.htm>