awareness: gcc/c++ version requirements mean RHEL7/CentOS7 can no longer be supported

[taw00]

Just so folks are aware, the gcc/c++ that ships with RHEL7/CentOS7 is v4.8. Alas, Dash Core 0.13 builds require newer versions. Newer versions can be installed via RH's "software collections" functionality, but in some cases static libraries are required... which don't come ship with RH's software collections.

After hitting roadblock after roadblock and spending days attempting to get 0.13 to build for EL7, I am throwing in the towel. I am filing this issue as a bookmark. RHEL8 looks to be coming out in May, but with 0.13, it looks like we have a supportability gap associated to the most bulletproof version of linux at the moment.

Thanks. -t0dd

PS. There are also cmake version issues, but EL7 does ship with the correct version with the cmake3 rpm package, though this does require a few conditional changes to some of the .mk files under dash-0.13.0*/depends/packages/

[nmarley]

Thanks for the info. We don't want to let OS release cycles hold back our development, and some of the newer code uses C++14 features and things only enabled in later versions of compilers.

I'll close this now but it should be available via Google search for those interesting in finding this useful bit of info.

[gituser]

Not only RHEL7, but also Debian 8 has been affected by this change too.

I've been building all previous Dash version just fine, but not v0.13.0.0.

Bitcoin new releases have been building just fine, but not dash.

Guess you've joined those cryptocurrency developers who only support fresh Ubuntu distros.

[taw00]

Updated comment... This is increasingly an issue for loads of projects, not just in the crypto-space. The drift from OS-blessed libraries and tooling is just too severe. I understand it, but it is unfortunate.

Other projects (to include Bitcoin) will have to update at some point as well, no doubt, in order to ensure their platform remains secure and maintained and has access to more currently peer-reviewed code. Additionally one can nitpick about complexity of builds (Bitcoin, for example is far too complex of a build for what it is, and by extension Dash -- Look to BEAM for an example of a simple and elegant build!).

I am not sure nitpicking these issues is helpful. Regardless, projects need to modernize. This issue was opened with the intend to bring awareness. Dash has been rock solid on Fedora for me for years now. I'm confident that will continue.

[gituser]

It is indeed.

However, bitcoin is still building on all platforms and that's why it's way more stable than other coins.

[codablock]

The reason we ignored/accepted that Dash 0.13 is not build-able on older OSes is that we release our binaries through Gitian builds, which create statically linked binaries which are downwards compatible to older OSes.

People on older OSes who want to self-compile without Gitian can still install newer GCC versions and use the depends subsystem for correct dependencies.

[taw00]

(updated my above comment, by the way... anyway...) I have toyed with the idea of building for Fedora (statically linked indeed), and then repackaging the binaries for RHEL and CentOS... but that broadens my testing footprint (and I just don't like that approach to packaging). I may reach out to others who have alerted me to the importance of this if they want to join in a test effort.

Fortunately, Dash on Fedora has been startlingly stable for all these years now. I am trying to recall a single crash in the last 3 years (due to code or build issues) and can't recall any.

[gituser]

The reason we ignored/accepted that Dash 0.13 is not build-able on older OSes is that we release our binaries through Gitian builds, which create statically linked binaries which are downwards compatible to older OSes.

People on older OSes who want to self-compile without Gitian can still install newer GCC versions and use the depends subsystem for correct dependencies.

Would be nice to get a clear documentation how to re-produce such a static build on different OS.

[codablock]

@gituser https://github.com/dashpay/dash/blob/master/doc/build-generic.md

[gituser]

@codablock Yes compilation process works on Ubuntu 16.04 (LTS).

However, it produces not 100% static files:

ldd dash*
dash-cli:
    linux-vdso.so.1 =>  (0x00007ffcf6730000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f46fc069000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f46fbe4c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f46fba82000)
    /lib64/ld-linux-x86-64.so.2 (0x0000556e6fcd6000)
dash-tx:
    linux-vdso.so.1 =>  (0x00007ffce32fa000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fadbf7a1000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fadbf58b000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fadbf36e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fadbefa3000)
    /lib64/ld-linux-x86-64.so.2 (0x000056329e82b000)
dashd:
    linux-vdso.so.1 =>  (0x00007ffdf3b55000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f337eafa000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f337e8e4000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f337e6c7000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f337e2fc000)
    /lib64/ld-linux-x86-64.so.2 (0x0000562353402000)

But Dash works on Debian 8 except I've needed to run first with -reindex.

[codablock]

@gituser Yeah it's not 100% statically linked, sorry if what I wrote gave that impression. It can't be 100% statically linked, because a few libs are not allowed to be statically linked as they otherwise cause serious issues. Luckily the ABI of these is so much set in stone or uses proper ABI versioning, that it's not an issue.

[taw00]

EL8 will be out in the middle of the year. All this will be a moot point (in the CentOS/RHEL world at least) before you know it.