fa33d97 [walletdb] Add missing LOCK() in Recover() for dummyWallet (MarcoFalke)
fa14d99 [qa] check if wallet or blochchain maintenance changes the balance (MarcoFalke)
fa0765d [qa] Cleanup wallet.py test (MarcoFalke)
3968922 c++11: fix libbdb build against libc++ in c++11 mode (Cory Fields)
57d2f62 c++11: CAccountingEntry must be defined before use in a list (Cory Fields)
89f71c6 c++11: don't throw from the reverselock destructor (Cory Fields)
76ac35f c++11: detect and correct for boost builds with an incompatible abi (Cory Fields)
noexcept is default for destructors as of c++11. By throwing in reverselock's
destructor if it's lock has been tampered with, the likely result is
std::terminate being called. Indeed that happened before this change.
Once reverselock has taken another lock (its ctor didn't throw), it makes no
sense to try to grab or lock the parent lock. That is be broken/undefined
behavior depending on the parent lock's implementation, but it shouldn't cause
the reverselock to fail to re-lock when destroyed.
To avoid those problems, simply swap the parent lock's contents with a dummy
for the duration of the lock. That will ensure that any undefined behavior is
caught at the call-site rather than the reverse lock's destruction.
Barring a failed mutex unlock which would be indicative of a larger problem,
the destructor should now never throw.
This is ugly, but temporary. boost::filesystem will likely be dropped soon
after c++11 is enabled. Otherwise, we could simply roll our own copy_file. I've
fixed this at the buildsystem level for now in order to avoid mixing in
functional changes.
Explanation:
If boost (prior to 1.57) was built without c++11, it emulated scoped enums
using c++98 constructs. Unfortunately, this implementation detail leaked into
the abi. This was fixed in 1.57.
When building against that installed version using c++11, the headers pick up
on the native c++11 scoped enum support and enable it, however it will fail to
link. This can be worked around by disabling c++11 scoped enums if linking will
fail.
Add an autoconf test to determine incompatibility. At build-time, if native
enums are being used (a c++11 build), and force-disabling them causes a
successful link, we can be sure that there's an incompatibility and enable the
work-around.
Jonas Schnelli