New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: Enable C++11 in build, require C++11 compiler #7165

Merged
merged 4 commits into from Apr 28, 2016

Conversation

Projects
None yet
@laanwj
Member

laanwj commented Dec 3, 2015

Implements #6211.

Just meant for testing for now. Probably doesn't pass Travis.

/usr/include/boost/filesystem/operations.hpp:381: undefined reference to `boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)'

TODO:

  • Travis fails on "This is not a C++11 compiler"

Possibly TODO:

  • Make sure Boost/Qt/BDB++ is compiled with c++11 in depends?

@laanwj laanwj added the Build system label Dec 3, 2015

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Dec 4, 2015

Member

Concept requete-ACK, of course, I don't think anybody will dare to nack this (besides tested nits [and making travis happy]).

Member

jtimon commented Dec 4, 2015

Concept requete-ACK, of course, I don't think anybody will dare to nack this (besides tested nits [and making travis happy]).

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Dec 4, 2015

Contributor

concept ACK

Contributor

dcousens commented Dec 4, 2015

concept ACK

@droark

This comment has been minimized.

Show comment
Hide comment
@droark

droark Dec 14, 2015

Contributor

Concept ACK.

Contributor

droark commented Dec 14, 2015

Concept ACK.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Dec 15, 2015

Member

Concept ACK, but only when it's determined to be safe (especially against possibly invisible consensus failures) and can be supported on all stable distros with standard OS libraries...

Member

luke-jr commented Dec 15, 2015

Concept ACK, but only when it's determined to be safe (especially against possibly invisible consensus failures) and can be supported on all stable distros with standard OS libraries...

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Dec 15, 2015

Contributor

on all stable distros

For reference, that list of distros:

  • Arch
  • Debian
  • Fedora
  • Gentoo stable
  • OS X
  • RHEL
  • Slackware
  • Ubuntu

Those ticked have native support of GCC ^5.1.y in the latest stable release (AFAIK). Please let me know if any corrections need to be made.

This doens't necessarily act as a block, assuming #6211 (comment)

Contributor

dcousens commented Dec 15, 2015

on all stable distros

For reference, that list of distros:

  • Arch
  • Debian
  • Fedora
  • Gentoo stable
  • OS X
  • RHEL
  • Slackware
  • Ubuntu

Those ticked have native support of GCC ^5.1.y in the latest stable release (AFAIK). Please let me know if any corrections need to be made.

This doens't necessarily act as a block, assuming #6211 (comment)

@droark

This comment has been minimized.

Show comment
Hide comment
@droark

droark Dec 15, 2015

Contributor

@dcousens - Don't forget Windows (well, MinGW)! I guess this one's a little tricky since the Windows build is cross-compiled. I think Ubuntu 14.04 will be fine, although 16.04 (LTS) will be necessary if GCC 5 features are required, I suppose, due to Gitian requirements.

Contributor

droark commented Dec 15, 2015

@dcousens - Don't forget Windows (well, MinGW)! I guess this one's a little tricky since the Windows build is cross-compiled. I think Ubuntu 14.04 will be fine, although 16.04 (LTS) will be necessary if GCC 5 features are required, I suppose, due to Gitian requirements.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Dec 15, 2015

Contributor

Maybe throw the switch once 16.04 (LTS) comes out and somebody can get Gitian to play nice with it?

That sounds OK to me, it seems like a realistic timeline too.

Contributor

dcousens commented Dec 15, 2015

Maybe throw the switch once 16.04 (LTS) comes out and somebody can get Gitian to play nice with it?

That sounds OK to me, it seems like a realistic timeline too.

@droark

This comment has been minimized.

Show comment
Hide comment
@droark

droark Dec 15, 2015

Contributor

That sounds OK to me, it seems like a realistic timeline too.

@dcousens - Sorry for editing what you replied to. :) But yeah, maybe aim for throwing the switch around the time 16.04 comes out if, for whatever reasons, it's decided that GCC 5 support is required/highly desirable. 15.10 has it but I think Gitian officially supports only LTS releases.

Contributor

droark commented Dec 15, 2015

That sounds OK to me, it seems like a realistic timeline too.

@dcousens - Sorry for editing what you replied to. :) But yeah, maybe aim for throwing the switch around the time 16.04 comes out if, for whatever reasons, it's decided that GCC 5 support is required/highly desirable. 15.10 has it but I think Gitian officially supports only LTS releases.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Dec 15, 2015

Member

Fedora can't be fully supported due to the ECDSA mess they've made. Disagree with it not being a blocker. Is GCC 5 now known to solve all the ABI issues, or at least the ones that could potentially affect Core?

Edit: Forgot we switched to libsecp256k1, nevermind re Fedora.

Member

luke-jr commented Dec 15, 2015

Fedora can't be fully supported due to the ECDSA mess they've made. Disagree with it not being a blocker. Is GCC 5 now known to solve all the ABI issues, or at least the ones that could potentially affect Core?

Edit: Forgot we switched to libsecp256k1, nevermind re Fedora.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Dec 17, 2015

Member

Ok, getting kind of tired of this, but postponing this another major release, I'm not going to push for this again.

Member

laanwj commented Dec 17, 2015

Ok, getting kind of tired of this, but postponing this another major release, I'm not going to push for this again.

@laanwj laanwj closed this Dec 17, 2015

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Dec 17, 2015

Contributor

@luke-jr No reason why Fedora cannot be supported. A fedora programmer added the following commit to picocoin, illustrating a Fedora-compatible approach: jgarzik/picocoin#44

Contributor

jgarzik commented Dec 17, 2015

@luke-jr No reason why Fedora cannot be supported. A fedora programmer added the following commit to picocoin, illustrating a Fedora-compatible approach: jgarzik/picocoin#44

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Dec 17, 2015

Member
Member

sipa commented Dec 17, 2015

@nathan-at-least

This comment has been minimized.

Show comment
Hide comment
@nathan-at-least

nathan-at-least Dec 17, 2015

I'm working on a fork off of Bitcoin core to implement zerocash. We require C++11 due to dependencies (eg libsnark).

It's not much effort to make C++11 compile, link, run, and pass make check. Hidden changes to consensus are another matter which we don't have a solid grasp on.

We've been working on a fork off of both v0.10.0 and v0.11.2 with g++ -std=c++11. This has required a few modifications to the upstream bitcoin code, different in each of these branches. Here are some notes (though I may be forgetting details).

First, some strong caveats:

  • Our only testing of consensus changes has been make check, so the following notes are only a starting point for C++11 support in bitcoin core. (Edit: -because we haven't done rigorous consensus regression testing. Any advice here would be greatly appreciated.)
  • On top of this, on our branch atop v0.10.0, we disabled many tests that had hard-coded test vectors (such as serialized structures from production main-net) rather than correctly fixing the tests.
  • On v0.11.2 we have not disabled any upstream tests, and have only added C++11 mode and linked in our extra dependencies. (The v0.10.0 is a messy proof of concept. Now we're starting fresh with more rigour.)
  • We only test/develop on debian or arch linux with non-"default' packages installed. Furthermore we only build with the depends system, something close to make -C ./depends NO_QT=1 && ./autogen.sh && ./configure --prefix=./depends/… --with-gui=no CXXFLAGS='-O0 -g' && make V=1
  • No one on our team has a strong C++ background. :-<

So, I scanned through our deltas from upstream to hunt down changes I believe are necessitated by C++11 support:

  • We've found that upgrading to boost 1.57.0 atop v0.10.0, or to either boost 1.57.0 or 1.59.0 atop bitcoin v0.11.2 resolves the linker error in @laanwj 's original comment.
    • The patches in ./depends/patches/boost do not apply to boost 1.57.0 (and we haven't tried them 1.59.0). I examined the 1.57.0 code to see if I could update the patches, but couldn't find relevant target code after about an hour of effort, so I gave up and deleted these patches! (I asked in #bitcoin-dev about this and at least one person told me that's probably ok because upstream probably addressed the same patched issue.)
  • Boost's list_of(x)(y)(z) syntax didn't work (for boost 1.57.0 atop bitcoin v0.10.0), so we switched to C++11 initializer syntax { x, y, z }.
  • In bitcoin v0.11.2 there is one unit test that relies on exceptions propagating out of a dtor: src/test/reverselock_tests.cpp L52-L58 at 7e278929. In C++11 this causes a process to abort unless you explicitly add an attribute to the dtor as in ~reverse_lock() noexcept(false) {…}.

I hope this helps. If I had time I'd work on this PR directly, but I can't promise anything.

nathan-at-least commented Dec 17, 2015

I'm working on a fork off of Bitcoin core to implement zerocash. We require C++11 due to dependencies (eg libsnark).

It's not much effort to make C++11 compile, link, run, and pass make check. Hidden changes to consensus are another matter which we don't have a solid grasp on.

We've been working on a fork off of both v0.10.0 and v0.11.2 with g++ -std=c++11. This has required a few modifications to the upstream bitcoin code, different in each of these branches. Here are some notes (though I may be forgetting details).

First, some strong caveats:

  • Our only testing of consensus changes has been make check, so the following notes are only a starting point for C++11 support in bitcoin core. (Edit: -because we haven't done rigorous consensus regression testing. Any advice here would be greatly appreciated.)
  • On top of this, on our branch atop v0.10.0, we disabled many tests that had hard-coded test vectors (such as serialized structures from production main-net) rather than correctly fixing the tests.
  • On v0.11.2 we have not disabled any upstream tests, and have only added C++11 mode and linked in our extra dependencies. (The v0.10.0 is a messy proof of concept. Now we're starting fresh with more rigour.)
  • We only test/develop on debian or arch linux with non-"default' packages installed. Furthermore we only build with the depends system, something close to make -C ./depends NO_QT=1 && ./autogen.sh && ./configure --prefix=./depends/… --with-gui=no CXXFLAGS='-O0 -g' && make V=1
  • No one on our team has a strong C++ background. :-<

So, I scanned through our deltas from upstream to hunt down changes I believe are necessitated by C++11 support:

  • We've found that upgrading to boost 1.57.0 atop v0.10.0, or to either boost 1.57.0 or 1.59.0 atop bitcoin v0.11.2 resolves the linker error in @laanwj 's original comment.
    • The patches in ./depends/patches/boost do not apply to boost 1.57.0 (and we haven't tried them 1.59.0). I examined the 1.57.0 code to see if I could update the patches, but couldn't find relevant target code after about an hour of effort, so I gave up and deleted these patches! (I asked in #bitcoin-dev about this and at least one person told me that's probably ok because upstream probably addressed the same patched issue.)
  • Boost's list_of(x)(y)(z) syntax didn't work (for boost 1.57.0 atop bitcoin v0.10.0), so we switched to C++11 initializer syntax { x, y, z }.
  • In bitcoin v0.11.2 there is one unit test that relies on exceptions propagating out of a dtor: src/test/reverselock_tests.cpp L52-L58 at 7e278929. In C++11 this causes a process to abort unless you explicitly add an attribute to the dtor as in ~reverse_lock() noexcept(false) {…}.

I hope this helps. If I had time I'd work on this PR directly, but I can't promise anything.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Dec 17, 2015

Contributor

@sipa It is directly related to luke's comment.

Contributor

jgarzik commented Dec 17, 2015

@sipa It is directly related to luke's comment.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Dec 17, 2015

Member
Member

sipa commented Dec 17, 2015

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Dec 17, 2015

Contributor

Agree - urge re-opening this - this is not a big risk.

Contributor

jgarzik commented Dec 17, 2015

Agree - urge re-opening this - this is not a big risk.

@laanwj laanwj reopened this Dec 17, 2015

@droark

This comment has been minimized.

Show comment
Hide comment
@droark

droark Dec 17, 2015

Contributor

Thanks for reopening, @laanwj.

One thing I would like to say is that some IBLT simulation code (non-Core) was written in C++11. I believe the plan is to try to recycle some of it for the eventual Core commit. It would be nice to know if C++11 will be acceptable so that everybody working on the Core patch(es) can use or modify code as necessary.

Also, I agree with @sipa. AFAIK, any library issues would come up as linker errors. I'm not aware offhand of any massive gotchas that would come with a switch to GCC 5 and a bit of time for distros to recompile everything. (AFAIK, Ubuntu did most of that before releasing 15.10, although it sounds like more work is needed for 16.04.) If anybody's aware of any specific issues, I'm all ears.

Contributor

droark commented Dec 17, 2015

Thanks for reopening, @laanwj.

One thing I would like to say is that some IBLT simulation code (non-Core) was written in C++11. I believe the plan is to try to recycle some of it for the eventual Core commit. It would be nice to know if C++11 will be acceptable so that everybody working on the Core patch(es) can use or modify code as necessary.

Also, I agree with @sipa. AFAIK, any library issues would come up as linker errors. I'm not aware offhand of any massive gotchas that would come with a switch to GCC 5 and a bit of time for distros to recompile everything. (AFAIK, Ubuntu did most of that before releasing 15.10, although it sounds like more work is needed for 16.04.) If anybody's aware of any specific issues, I'm all ears.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Dec 17, 2015

Member

This was discussed in the weekly IRC meeting. It seems we'll aim for C++11 in 0.13, by first adding build configuration and testing for C++11 on some targets (but not all), and if no problems appear, switch everything to C++11 and start using C++11 features.

Member

sipa commented Dec 17, 2015

This was discussed in the weekly IRC meeting. It seems we'll aim for C++11 in 0.13, by first adding build configuration and testing for C++11 on some targets (but not all), and if no problems appear, switch everything to C++11 and start using C++11 features.

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni Dec 17, 2015

Member

Looks like the only remaining issue in that list should be the throwing dtor.

Member

theuni commented Dec 17, 2015

Looks like the only remaining issue in that list should be the throwing dtor.

@nathan-at-least

This comment has been minimized.

Show comment
Hide comment
@nathan-at-least

nathan-at-least Dec 18, 2015

The patch for the dtor "fix" is:

diff --git a/src/reverselock.h b/src/reverselock.h
index 567636e..db5c626 100644
--- a/src/reverselock.h
+++ b/src/reverselock.h
@@ -17,7 +17,7 @@ public:
         lock.unlock();
     }

-    ~reverse_lock() {
+    ~reverse_lock() noexcept(false) {
         lock.lock();
     }

This allows reverselock_error test to pass (link in my prior comment). However, it makes me uncomfortable because I don't understand if both enabling c++11 and adding this attribute will lead to identical behavior as before.

This patch is enabling a mechanism used for test verification, but we may not want that behavior in the application code. The only use I see is in src/scheduler.cpp L73 at cd3f12c6 (latest on branch master).

nathan-at-least commented Dec 18, 2015

The patch for the dtor "fix" is:

diff --git a/src/reverselock.h b/src/reverselock.h
index 567636e..db5c626 100644
--- a/src/reverselock.h
+++ b/src/reverselock.h
@@ -17,7 +17,7 @@ public:
         lock.unlock();
     }

-    ~reverse_lock() {
+    ~reverse_lock() noexcept(false) {
         lock.lock();
     }

This allows reverselock_error test to pass (link in my prior comment). However, it makes me uncomfortable because I don't understand if both enabling c++11 and adding this attribute will lead to identical behavior as before.

This patch is enabling a mechanism used for test verification, but we may not want that behavior in the application code. The only use I see is in src/scheduler.cpp L73 at cd3f12c6 (latest on branch master).

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Dec 18, 2015

Member

c++11 for 0.13? I should miss more meetings so things go more my way...

Member

jtimon commented Dec 18, 2015

c++11 for 0.13? I should miss more meetings so things go more my way...

@laanwj laanwj added the Refactoring label Feb 16, 2016

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Mar 16, 2016

Member

what's the latest status on this?

Member

jtimon commented Mar 16, 2016

what's the latest status on this?

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 16, 2016

Member

what's the latest status on this?

@theuni has been chasing Travis about dependency caching support on the VMs that support c++11 (Ubuntu 14.04+)
We could in principle do without it, disabling qt builds - or using the distro's native qt development headers, but if possible it'd be preferable to keep using the current system.
That's what holding it up.

Member

laanwj commented Mar 16, 2016

what's the latest status on this?

@theuni has been chasing Travis about dependency caching support on the VMs that support c++11 (Ubuntu 14.04+)
We could in principle do without it, disabling qt builds - or using the distro's native qt development headers, but if possible it'd be preferable to keep using the current system.
That's what holding it up.

@MarcoFalke MarcoFalke referenced this pull request Apr 16, 2016

Merged

[qa] Switch to py3 #7814

1 of 1 task complete
@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Apr 17, 2016

Member

Wouldn't you need to bump travis to trusty as part of this pull?

Member

MarcoFalke commented Apr 17, 2016

Wouldn't you need to bump travis to trusty as part of this pull?

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 18, 2016

Member

@theuni is working on that

Member

laanwj commented Apr 18, 2016

@theuni is working on that

@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Apr 26, 2016

Member

Travis failure:

configure: error: *** A compiler with support for C++11 language features is required.

Maybe retrigger after the cache for master is populated? Otherwise a rebase/fresh commit is needed because travis is not building against master.

Member

MarcoFalke commented Apr 26, 2016

Travis failure:

configure: error: *** A compiler with support for C++11 language features is required.

Maybe retrigger after the cache for master is populated? Otherwise a rebase/fresh commit is needed because travis is not building against master.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 26, 2016

Member

Okay, rebased to master.

Member

laanwj commented Apr 26, 2016

Okay, rebased to master.

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni Apr 26, 2016

Member

@laanwj theuni@deaf59f Should get this up and going. clang needs an explicit -stdlib=libc++ for darwin.

Member

theuni commented Apr 26, 2016

@laanwj theuni@deaf59f Should get this up and going. clang needs an explicit -stdlib=libc++ for darwin.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 27, 2016

Member

@theuni thanks, cherry-picked

Member

laanwj commented Apr 27, 2016

@theuni thanks, cherry-picked

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni Apr 27, 2016

Member

Woohoo, ACK!

Member

theuni commented Apr 27, 2016

Woohoo, ACK!

@droark

This comment has been minimized.

Show comment
Hide comment
@droark

droark Apr 27, 2016

Contributor

Nice! Code looks good to me. Untested ACK.

Contributor

droark commented Apr 27, 2016

Nice! Code looks good to me. Untested ACK.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Apr 27, 2016

Member

utACK a398549

Member

sipa commented Apr 27, 2016

utACK a398549

@paveljanik

This comment has been minimized.

Show comment
Hide comment
@paveljanik

paveljanik Apr 27, 2016

Contributor

ACK a398549

configure output diff on OS X:

+checking whether g++ supports C++11 features by default... no
+checking whether g++ supports C++11 features with -std=c++11... yes

and the build log contains millions of added -std=c++11 as expected.

Contributor

paveljanik commented Apr 27, 2016

ACK a398549

configure output diff on OS X:

+checking whether g++ supports C++11 features by default... no
+checking whether g++ supports C++11 features with -std=c++11... yes

and the build log contains millions of added -std=c++11 as expected.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Apr 27, 2016

Contributor

No longer the latest version of the C++11 macro (see http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_cxx_compile_stdcxx.m4). Do we want to update?

Contributor

TheBlueMatt commented Apr 27, 2016

No longer the latest version of the C++11 macro (see http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_cxx_compile_stdcxx.m4). Do we want to update?

@droark

This comment has been minimized.

Show comment
Hide comment
@droark

droark Apr 27, 2016

Contributor

Tested ACK with the latest C++11 macro, as pointed out by Matt. Compiles fine on the latest OS X (10.11.4) and Xcode (7.3), make check passes, and I get the same output as Janik.

Contributor

droark commented Apr 27, 2016

Tested ACK with the latest C++11 macro, as pointed out by Matt. Compiles fine on the latest OS X (10.11.4) and Xcode (7.3), make check passes, and I get the same output as Janik.

@randy-waterhouse

This comment has been minimized.

Show comment
Hide comment
@randy-waterhouse

randy-waterhouse Apr 28, 2016

Contributor

ACK. builds, tests, runs.

Throws a new build warning
"httpserver.cpp:255:36: warning: ‘auto_ptr’ is deprecated ..."

Contributor

randy-waterhouse commented Apr 28, 2016

ACK. builds, tests, runs.

Throws a new build warning
"httpserver.cpp:255:36: warning: ‘auto_ptr’ is deprecated ..."

@paveljanik

This comment has been minimized.

Show comment
Hide comment
@paveljanik

paveljanik Apr 28, 2016

Contributor

@randy-waterhouse What compiler do you use please?

Edit: Travis has the warning here: https://travis-ci.org/bitcoin/bitcoin/jobs/126071750#L3267

Contributor

paveljanik commented Apr 28, 2016

@randy-waterhouse What compiler do you use please?

Edit: Travis has the warning here: https://travis-ci.org/bitcoin/bitcoin/jobs/126071750#L3267

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni Apr 28, 2016

Member

@paveljanik That's a legitimate warning. We'll need to auto_ptr -> unique_ptr. But that's a hard fork :p

Member

theuni commented Apr 28, 2016

@paveljanik That's a legitimate warning. We'll need to auto_ptr -> unique_ptr. But that's a hard fork :p

@fanquake

This comment has been minimized.

Show comment
Hide comment
@fanquake

fanquake Apr 28, 2016

Member

Tested on OSX 10.11.4 & Xcode 7.3. compiles fine, make check passes. Same configure diff as above.

Member

fanquake commented Apr 28, 2016

Tested on OSX 10.11.4 & Xcode 7.3. compiles fine, make check passes. Same configure diff as above.

@laanwj laanwj changed the title from WIP: build: Enable C++11 in build, require C++11 compiler to build: Enable C++11 in build, require C++11 compiler Apr 28, 2016

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Apr 28, 2016

Member

removed WIP: tag, added commit that updates ax_cxx_compile_stdcxx (thanks @TheBlueMatt for noticing)

@randy-waterhouse Indeed, the auto_ptr should be replaced, let's do that in a later pull.

Member

laanwj commented Apr 28, 2016

removed WIP: tag, added commit that updates ax_cxx_compile_stdcxx (thanks @TheBlueMatt for noticing)

@randy-waterhouse Indeed, the auto_ptr should be replaced, let's do that in a later pull.

@paveljanik

This comment has been minimized.

Show comment
Hide comment
@paveljanik

paveljanik Apr 28, 2016

Contributor

reACK 2aacc72

Contributor

paveljanik commented Apr 28, 2016

reACK 2aacc72

@laanwj laanwj merged commit 7df9224 into bitcoin:master Apr 28, 2016

laanwj added a commit that referenced this pull request Apr 28, 2016

Merge #7165: build: Enable C++11 in build, require C++11 compiler
7df9224 doc: Add note about new build/test requirements to release notes (Wladimir J. van der Laan)
2aacc72 build: update ax_cxx_compile_stdcxx to serial 4 (Wladimir J. van der Laan)
a398549 depends: use c++11 (Cory Fields)
67969af build: Enable C++11 build, require C++11 compiler (Wladimir J. van der Laan)

@str4d str4d referenced this pull request Oct 29, 2017

Merged

Darwin build fixes #2697

zkbot added a commit to zcash/zcash that referenced this pull request Nov 29, 2017

Auto merge of #2697 - str4d:darwin-build, r=<try>
Darwin build fixes

Includes fixes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7136
  - Only the third commit (to avoid a merge conflict)
- bitcoin/bitcoin#7302
  - Excluding the first commit, which is unnecessary (we use Boost 1.62)
- bitcoin/bitcoin#7487
- bitcoin/bitcoin#7606
- bitcoin/bitcoin#7711
- bitcoin/bitcoin#7165
- bitcoin/bitcoin#8002
- bitcoin/bitcoin#8210
  - Only the second commit
- bitcoin/bitcoin#9114

zkbot added a commit to zcash/zcash that referenced this pull request Nov 30, 2017

Auto merge of #2697 - str4d:darwin-build, r=<try>
Darwin build fixes

Includes fixes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7136
  - Only the third commit (to avoid a merge conflict)
- bitcoin/bitcoin#7302
  - Excluding the first commit, which is unnecessary (we use Boost 1.62)
- bitcoin/bitcoin#7487
- bitcoin/bitcoin#7606
- bitcoin/bitcoin#7711
- bitcoin/bitcoin#7165
- bitcoin/bitcoin#8002
- bitcoin/bitcoin#8210
  - Only the second commit
- bitcoin/bitcoin#9114

zkbot added a commit to zcash/zcash that referenced this pull request Nov 30, 2017

Auto merge of #2697 - str4d:darwin-build, r=str4d
Darwin build fixes

Includes fixes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7136
  - Only the third commit (to avoid a merge conflict)
- bitcoin/bitcoin#7302
  - Excluding the first commit, which is unnecessary (we use Boost 1.62)
- bitcoin/bitcoin#7487
- bitcoin/bitcoin#7606
- bitcoin/bitcoin#7711
- bitcoin/bitcoin#7165
- bitcoin/bitcoin#8002
- bitcoin/bitcoin#8210
  - Only the second commit
- bitcoin/bitcoin#9114

zkbot added a commit to zcash/zcash that referenced this pull request Nov 30, 2017

Auto merge of #2697 - str4d:darwin-build, r=str4d
Darwin build fixes

Includes fixes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7136
  - Only the third commit (to avoid a merge conflict)
- bitcoin/bitcoin#7302
  - Excluding the first commit, which is unnecessary (we use Boost 1.62)
- bitcoin/bitcoin#7487
- bitcoin/bitcoin#7606
- bitcoin/bitcoin#7711
- bitcoin/bitcoin#7165
- bitcoin/bitcoin#8002
- bitcoin/bitcoin#8210
  - Only the second commit
- bitcoin/bitcoin#9114
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment