Document minimum versions of build dependencies

[MarkusTeufelberger]

https://ripple.com/build/rippled-setup/#installing-rippled links to https://wiki.ripple.com/Rippled_build_instructions which is quite out of date by now (e.g. still mentioning the recently removed JS test suite).

Please document the currently recommended minimum versions for the following components used to build rippled:
OpenSSL
Boost
Clang
GCC
Protoc/protobuf
SCons

For example, there seem to be some bugs when combining certain versions of Boost-Coroutines and Address Sanitizer and rippled checks in its build process the version of OpenSSL, refusing to build with insecure/old versions of that library.

[MarkusTeufelberger]

I want to run complete build tests in various Linux distributions via Docker, but it is hard to know for which component I should look for a more recent package than what is available at that current distribution's repository. I want to do this because distribution specific patches can hide/mask issues (like #1432)

[MarkusTeufelberger]

I have yet to find a single Linux distribution where I can simply do the following 3 things:

• Install build dependencies from the official distribution's repository
• git pull rippled
• run Builds/build_all.sh with no errors

I've tried so far: Alpine 3.5/edge, Archlinux, CentOS 7, Debian Jessie/Stretch/Sid, Fedora 25/rawhide and Ubuntu 16.04/16.10/17.04 [Edit and OpenSUSE 42.2/Tumbleweed]

I've filed a few bugs, currently the biggest issue seem to be with missing OpenSSL support and a slightly obscure ASAN <--> boost issue that presumably got fixed in llvm 3.9 (http://llvm.org/viewvc/llvm-project?view=revision&revision=273260) which has apparently not yet landed in a lot of distros. The ones that have a very recent clang also tend have very recent OpenSSL versions...

Alpine Linux is affected by at least #2048.

Arch Linux has the issue that the SConstruct file hardcodes the way static libraries are linked, but they do not even ship static libraries, so the linker fails.

[Edit: OpenSUSE 42.2 fails because C++14 is not supported and gcc6 is not easily installed there (but available), Tumbleweed seems close to working, but has the same issue as Arch Linux with static libraries not being shipped yet assumed to be present due to the way they are inserted into the linker by scons.]

I tried to include Dockerfiles to every bug report, so it should be easier to reproduce. Once I get a few distros to actually completely build + test rippled in all variants, I'll provide my test files so this can be run as a long running regression test.

[gituser]

Did it work for you on Debian Jessie? For me it failed completely... I had to spin up Ubuntu 16.04 VM because of the GCC 5 requirement..

[MarkusTeufelberger]

Most promising are Fedora, OpenSUSE and Arch with at least some popular build versions succeeding (but not all)... others either have too old GCC/Clang versions or too new OpenSSL versions. ASAN and especially TSAN builds seem to have bigger issues, I wonder if/how Ripple tests them regularly.

[gituser]

Yeah.. I don't really get why there is such a need for GCC 5.. Basically cutting off a lot of users from various distros.

[MarkusTeufelberger]

Rippled source code is written in a relatively new C++ dialect, it is the distro's fault if they don't provide an officially supported way to get a modern compiler for a language spec that is a few years old by now. More stale than stable...

[gituser]

@MarkusTeufelberger I've been working with various cryptocoins and this is probably the first one which requires bleeding edge versions of the compiler.

Also, from the first glance it seems rippled is more focused to work on RHEL / CentOS 7 family rather than on Ubuntu. Though there are some instructions to compile on Ubuntu as well.. But would be better if they could build native debian/ubuntu (dpkg) packages for Ubuntu instead of this alien hack converting rpm to debian packages..

Maybe, you are right about "stale", but for me stability means a lot in the production environment. That's why I don't like putting Ubuntu at all in the production environment or very recent versions of the distros which are not well tested.

[MarkusTeufelberger]

GCC 5 is 2 years old and several versions behind the current release, including a major one. I wouldn't call that "bleeding edge".

Yeah, it is a bit weird, their Travis-ci tests run on Ubuntu and some bugs were closed as unreproducible because of specific Debian/Ubuntu patches, yet they only publish RPMs. I guess that's because their infrastructure seems to still just run on Amazon and probably uses their RPM based distro, so internally they don't need much more than that.

The default build (just running "scons && build/rippled -u") completes successfully on:
Arch, Fedora 25, OpenSUSE 42.2/tumbleweed, Ubuntu 16.04/16.10./17.04
It fails on Alpine 3.5/edge, CentOS 7, Debian Jessie/Sid/Stretch and Fedora rawhide.

I'll run another round with the current version, I ran my full test suite 2 weeks ago, but it takes a few days to go through everything.

Edit:
I don't really want to start reporting issues that creep up when building here however until this issue is resolved, since most seem to stem from too old/new versions while it is not really possible to know right now which ones are actually intended to work. Travis and the RPM builder both use a cobbled together build environment that probably isn't able to run Builds/build_all.sh either without errors. There is no clear build platform targeted, it used to be Ubuntu LTS on the deprecated wiki page.

[nbougalis]

I am going to close this issue. We are going to try to officially support more Linux distributions, and would welcome efforts by third parties that wish to become maintainers for specific distributions that our team can't work on.

[MarkusTeufelberger]

Required Boost versions are now being documented in the changelog by the way, in case someone finds this issue in the future.

[nbougalis]

We should have that information in an md file that's at the root of the repo in addition to the changelog.