Opening an issue after some recent IRC discussion about moving to requiring C++14.
C++14 is available from GCC 5, and is the default mode in GCC 6.1. “The default mode for C++ is now -std=gnu++14 instead of -std=gnu++98.”. We currently require GCC 4.8+.
C++14 is available from Clang 3.4+. We currently require Clang 3.3+.
We currently already use shared mutex.
Also should check OpenSuse and CentOS.
According to today’s irc chat debian oldstable will only support C++14 in time for our ~0.19.0 release:
https://botbot.me/freenode/bitcoin-core-dev/2018-05-31/?msg=100660663&page=4
Some time have passed – do the milestones still hold?
Looking forward to the C++14 switch :-)
@practicalswift Unless there are any objections, we can do the switch on the day that master is branched from 0.18.0.
See #14438
02019-03-01
1-----------
2- Split off `0.18` branch from `master`
The pull request itself can be prepared and reviewed in advance, of course.
@JeremyRubin Miners routinely modify their software and we encourage them to do so (at least in various sensible ways). If you can’t compile you can’t run your modifications. Also, and perhaps more importantly, critical fixes are always first available as source code.
Before we actually experienced the issue I would have regarded the concern as largely hypothetical, it was an excusable mistake. I don’t see why we shouldn’t learn from that mistake…
Rapidly advancing the required language version has costs. These costs could be justified with commiserate benefits, but I’m not aware of a case being made here.
Thanks for the information on that @gmaxwell. I was unaware that there was an issue with that during SegWit – do you have any link to discussion on this? I was unable to find it in my bitcoin-dev email archives, just this article https://www.nasdaq.com/article/where-bitcoin-mining-pools-stand-on-segregated-witness-cm713991 / tweet https://twitter.com/satofishi/status/843910700124717058 @luke-jr I know that’s generally true (e.g., Linux, Windows, and OSX). But I figured for Bitcoin the compatibility is sufficient across most linux distributions so as not to require recompilation per-distro. Perhaps it depends on what kinds of changes miners are compiling in…
anyways, I’m indifferent on if to upgrade to 14 or not (the changes in 14 are relatively minor and low advantage compared to say, 17). Just wanted to learn more about the practical issue.
There is basically no compatibility across Linux distributions, even different versions of the same distro are likely to have issues sometimes.
And despite our efforts to build a hacky gitian static binary that is supposed to run everywhere, in practice even that seems to be a failure (I can’t run them!). In any case, the gitian process currently includes a significant amount of trust, and people shouldn’t be required to use its binaries.
The current released version of RHEL is still on GCC 4.8, and even when things are released we can’t expect users to be instantly upgraded.
Just want to note that RHEL 8 (with GCC 8.2) has been out for half a year now. And Ubuntu 18.04 has gcc-8 in universe.
Which distributions are most popular with miners?
Some might be using CentOS 7
Red Hat has a devtoolset software collection that provides a new version of gcc and such for either RHEL or CentOS. I get gcc 8.3.1 on CentOS 7 if I run:
0# yum install centos-release-scl
1# yum install devtoolset-8
2# scl enable devtoolset-8 bash
3# gcc --version | head -n1
4gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
5# exit
6# gcc --version | head -n1
7gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Doing yum install boost-devel libevent-devel openssl-devel lets me build with --disable-wallet in that environment. I think that should let you get a newer compiler on RHEL/CentOS 6 as well? Looks like clang is available too.
Labels
Brainstorming
Build system
Milestone
Future