Disabling warnings can be tricky, because doing so can cause a different
compiler to create new warnings about unsupported disable flags. Also, some
warnings don't surface until they're paired with another warning (gcc). For
example, adding "-Wno-foo" won't cause any trouble, but if there's a legitimate
warning emitted, the "unknown option -Wno-foo" will show up as well.
Work around this in 2 ways:
1. When checking to see if -Wno-foo is supported, check for "-Wfoo" instead.
2. Enable -Werror while checking 1.
If "-Werror -Wfoo" compiles, "-Wno-foo" is almost guaranteed to be supported.
-Werror itself is also checked. If that fails to compile by itself, it likely
means that the user added a flag that adds a warning. In that case, -Werror
won't be used while checking, and the build may be extra noisy. The user would
need to fix the bad input flag.
Also, silence 2 more additional warnings that can show up post-c++11.
The NSIS script tried to delete wxwidgets-based executables/locales. These files are ancient, and presumably no users have them anymore, so we can simplify the NSIS script by removing those lines.
Replaces the hardcoded string "bitcoin" with the autoconf variable PACKAGE_TARNAME; fixes#7265.
Places where I chose not to replace:
1. bitcoin.ico wasn't replaced because it doesn't seem to be relevant to the build system and its filename never affects the end user.
2. InstallDir wasn't replaced because the current text has an uppercase B, and I'm not sure of a good way to capitalize the result of PACKAGE_TARNAME.
3. A comment in the Main Installer section wasn't replaced because comments don't ever face the end user.
4. The registry value "URL:Bitcoin" wasn't replaced for the same reason as InstallDir.
5. Startup shortcut wasn't replaced for the same reason as InstallDir.
All other appearances of "bitcoin" were replaced with PACKAGE_TARNAME, except for the bin names, which were instead replaced with the new bin name autoconf variables.
Due to include ordering, defining in one place was not enough to ensure correct
usage. Use global defines so that we don't have to worry abou this ordering.
Also add a comment in configure about the test.
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.
The output should always match openssl's, even for failed operations. Even for
a decrypt with broken padding, the output is always deterministic (and attemtps
to be constant-time).
Before this, if someone imported a scriptPubKey directly (in hex form) using
importaddress, outputs sending to it would be treated as change, as the
corresponding CTxDestination was not added to the address book.
Fix this by trying to detect scriptPubKeys that are in fact convertible to a
CTxDestination and add them anyway. Add a warning to the RPC help to warn
against importing raw non-standard scripts.
