<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2017 at 17:30, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_2204533888642656808m_-7425938371627968870m_9126358848075431994gmail-">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></span><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><span class="m_2204533888642656808m_-7425938371627968870m_9126358848075431994gmail-"><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></span><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></div></div></blockquote><div><br></div><div>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 <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 class="gmail_extra"><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="m_2204533888642656808m_-7425938371627968870m_9126358848075431994gmail-m_-9084288760206849131gmail-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></blockquote><div><br></div><div>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_leng<wbr>th@@CXXABI_1.3.8<br><br>As you can see from<br><a href="http://packages.ubuntu.com/search?keywords=libstdc%2B%2B6" target="_blank">http://packages.ubuntu.com/sea<wbr>rch?keywords=libstdc%2B%2B6</a><br></div><div>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.<br><br></div><div>I managed to get rid of that symbol easily.<br><br></div><div>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.<br></div><div>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)<br></div><div><br></div><div>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.<br></div></div><br></div></div>