Reproducible binary builds [was: complibs/zlib: Add zlib support for binutils and gdb]

[Michael Hope <michael dot hope at linaro dot org>]

Hi there.  I thought I'd pop this out of the zlib discussion as the
thread was getting a bit deep.  Take it back to the top level
requirements and such.

We're looking at making and distributing a binary build of the Linaro
toolchain for ARM.

We want:
 * A generic Linux build that runs on most distros from RHEL 5 onwards
 * A Windows build that runs on Windows XP and up
 * Support for 32 bit and 64 bit hosts

and various qualities that go with that:
 * Reproducible builds
 * A sharable build system so others can reproduce and customise the build
 * A minimum number of binaries, meaning that the binary should run on
32 and 64 bit hosts
 * To minimise testing by making the Windows and Linux builds as
similar as possible

To do this it makes sense to:
 * Use the same build scripts (i.e. crosstool-NG) for Windows and Linux
 * Use the same library and application versions
 * Build everything from scratch

We could pick something like Ubuntu 8.04 LTS and build on that to lock
down the library versions, but that makes it hard to have the same
version on Windows and harder for others to reproduce the build.

We could use the prebuilt mingw/msys versions of libraries (such as
http://sourceforge.net/projects/mingw/files/MinGW/Base/libiconv/libiconv-1.14-2/)
but then the Windows and Linux versions would be different.

There's a few options for running on a range of Linuxs':
 1. Statically link everything (lose any security/bug fixes)
 2. Statically link everything but libc and libm
 3. Use LSB
 4. Ship dynamic libraries and pick them up using RPATH

A 32 bit version of (1) ill work out-of-the-box on 32 bit and 64 bit
hosts.  None of the rest will as 64 bit hosts don't include the 32 bit
libraries by default, but they're pretty close and just a 'apt-get
install lsb' or 'yum install redhat-lsb.i386' away.

The biggest thing is to use the same versions on Windows and Linux
which really means building from scratch.  Re-using the crosstool-NG
infrastructure makes more sense then doing it outside.  I'm happy to
keep these patches in our own tree so that it doesn't pollute tip and
increase the number of packages you need to support.

-- Michael

--
For unsubscribe information see http://sourceware.org/lists.html#faq