[Development] Linux release binaries too old

[Thiago Macieira]

On Monday 25 August 2014 15:25:26 Blasche Alexander wrote:
> Hi,
> 
> It is my understanding that the current Linux release binary packages are
> built on Ubuntu 11.10 machines. This is very ancient. In fact for Bluetooth
> Low Energy (new feature in 5.4) this is too ancient.
> 
> What's needed is a machine that has Bluez 4.101 or newer. This means even
> the fairly old 12.04 is too old unless we retrofit those newer headers. If
> we don't want to retrofit and assuming we want to stay with Ubuntu we'd
> require 14.04.
> 
> Bluetooth requires the newer headers only at build time. I tested binaries
> on 12.04 by faking the new symbols and it still seemed to work.
> 
> The question is how many old distros do we leave behind? Bluez 4.101 was
> released in June 2012. If distros update Qt they are likely to recompile
> anyway.

TL;DR: no, we can't do this upgrade.

Distros compiling Qt is not an issue.

The question here is whether our updating of the machines we use to compile 
our distro-independent binaries will cause our Qt to fail to run on certain 
distros.

The only way to be absolutely sure is to make that build, then take the older 
distros that are target and run ldd -d -r on each and every .so, to see if 
there are symbols not found.

I can't do that. However, I can do an approximation by checking ELF symbol 
versions. This test is necessary to guarantee compatibility, but is not 
sufficient (there may be new, symbols in libraries that don't use versioning). 
We know that glibc and libstdc++ do version properly, so a quick check of all 
libs and plugins in my build resulted in the following ELF versions in use for 
libc.so.6 and libstdc++.so.6:

CXXABI_1.3
GCC_3.0
GCC_4.0.0
GLIBC_2.10
GLIBC_2.14
GLIBC_2.15
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.4
GLIBC_2.7
GLIBC_2.9
GLIBCXX_3.4
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.5
GLIBCXX_3.4.9

I have GCC 4.8.2 (same as Ubuntu 14.04) and Glibc 2.18 (Ubuntu 14.04 has 
2.19). A quick check in glibc's source code reveals no symbols with GLIBC_2.19 
that affect us (only S/390, MIPS, PPC, and HP-PA). So the listing above should 
be equivalent to the Ubuntu 14.04 build.

GLIBCXX 3.4.15 came with GCC 4.6.0, so this build would automatically exclude 
any distro having GCC older than that. Fortunately for us, Ubuntu 11.10 
already had 4.6.1, so we wouldn't be excluding anything with the upgrade.

The minimum glibc version also to be 2.15, whereas our current requirement is 
2.13. A quick search for the symbols marked GLIBC_2.14 and 15 shows two 
culprits:

	memcpy		2.14 (64-bit builds only)
	fallocate64	2.15 (32-bit builds only, affects sqlite plugin)

There's absolutely no way we can work around the memcpy function being 
different. 

That would mean these are the minimum versions the popular distros (release 
month in parentheses):
	Arch (rolling release)
	CentOS 7.0 (7/2014)
	Debian testing (no release!)
	Fedora 17 (5/2012)
	Mageia 3 (5/2013)
	Mint 13 (5/2012)
	OpenSUSE 12.2 (9/2012)
	Ubuntu 12.04 (4/2012)

In other words, by upgrading our Ubuntu 11.10 build, we'll drop support for 
any released Debian. I don't think we can do it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center