build: use Ubuntu 12.04 for linux gitian build #3536

Work on #3533.

This successfully builds on Ubuntu 12.04. Also upgrades the miniupnpc and qrencode dependencies to the same versions as #3527.

@theuni do you maybe have suggestions on how to make static building possible again? (see above) Maybe we could add an configure flag for that or so?

After forcing static linking there is also a -fPIC problem on 64 bit. The static boost libraries on Ubuntu are built without -fPIC/PIE/pie, which gives a relocation conflict with bitcoin that is built with -pie.

/usr/bin/ld: /usr/lib/libboost_system.a(error_code.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

This goes away after removing -pie. But to make this work we likely need to build boost from source as well?

Assuming it builds, ACK. The statically linked libraries issues needs to be fixed, but that seems independent from this PR.

Would it be reasonable to make the deps in a separate .yml? They don't change often and it would allow building the important part faster.

@wtogami Yes that makes sense, especially if it turns out that we have to build boost from scratch too to have static compilation + -pie. However I don't know how this dependency stuff will work with multi-arch builds. The dependency build will obviously produce a file per architecture, but can we use an architecture-specific input?

Edit: I guess I can just put both architecture dependencies files as inputs, and then select the one to use based on the current arch (uname -m).

Edit.2: could someone have told me about GBUILD_BITS?!? :p

In the new commit I've split off the dependency build for Linux.

Edit: re-working to use ${GBUILD_BITS} and to not drop 32 and 64 bit builds on top of each other in the final output

OK should be ready for review/merge. It's able to build executables that an be used on Ubuntu 12.04 which can be called usable.

According to readelf -d the end result relies on the following shared libraries, but these are all available in Ubuntu packages:

0x0000000000000001 (NEEDED)             Shared library: [libboost_system.so.1.46.1]
0x0000000000000001 (NEEDED)             Shared library: [libboost_filesystem.so.1.46.1]
0x0000000000000001 (NEEDED)             Shared library: [libboost_program_options.so.1.46.1]
0x0000000000000001 (NEEDED)             Shared library: [libboost_thread.so.1.46.1]
0x0000000000000001 (NEEDED)             Shared library: [libQtGui.so.4]
0x0000000000000001 (NEEDED)             Shared library: [libQtNetwork.so.4]
0x0000000000000001 (NEEDED)             Shared library: [libQtCore.so.4]
0x0000000000000001 (NEEDED)             Shared library: [libQtDBus.so.4]
0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.0.0]
0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.1.0.0]
0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

• Relying on dynamic Qt: good, as it means free integration into the desktop environment using appmenu-qt and friends). Also there is no end to that rabbit hole: if you statically link Qt, you create a direct dependency on a ton of X11 libraries.
• Relying on dynamic OpenSSL: can be both an advantage and disadvantage (depending on how up to date the distribution is keeping them)
• Relying on dynamic Boost: BAD. This means we need a specific boost package installed, also boost 1.46 is old and it's all that can be relied on to be present on Ubuntu 12.04.

I'm going to roll a boost-linux.yml dependency package with static boost, so that Linux is able to use boost 1.55 as well. But not for this pull.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/04257151b14da2a7dbfce8fd6f8d5d5835169ea1 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

Dynamic openssl makes prohibitively difficult for Red Hat and Fedora users to use the official binaries. Please revert that change.

@wtogami I haven't changed that! I'm just trying to improve what is there.

That's a good argument for using our own OpenSSL but we NEVER built our own OpenSSL for Linux yet. This is extra work, not a reversion.

It's a regression caused by the autotools switch, I presume. Causing problems for RHEL/Fedora is a good reason for statically linking OpenSSL, but this PR has nothing to do with that.

I'm not sure how to address the comments here without first discussing what the goals are. Is the goal a static universal binary? Or a distro-friendly one?

As for producing a static build, that can happen via LDFLAGS, or by ensuring that no shared libs exist in searched linker paths. The specifics are quite environment specific, not to be handled by our buildsystem imo.

Dynamic qt4 is well tested and proven to work on all Linux distros.

Dynamic openssl is impossible due to RHEL/Fedora. Static openssl is the only way the official binary can work on all distros.