Age | Commit message (Collapse) | Author |
|
|
|
Fedora 33 requires adding the Cheese third-party repo to install
libdb4-devel and libdb4-cxx-devel packages.
|
|
This package is currently installed as a side-effect of installing our
other libboost-*-dev packages. However as those continue to dissapear,
it makes sense to install boost dev explicitly.
|
|
060a2a64d40d75fecb60b7d2b9946a67e46aa6fc ci: remove boost thread installation (fanquake)
06e1d7d81d5a56d136c6fc88f09a2b0654a164f9 build: don't build or use Boost Thread (fanquake)
7097add83c8596f81be9edd66971ffd2486357eb refactor: replace Boost shared_mutex with std shared_mutex in sigcache (fanquake)
8e55981ef834490c438436719f95cbaf888c4914 refactor: replace Boost shared_mutex with std shared_mutex in cuckoocache tests (fanquake)
Pull request description:
This replaces `boost::shared_mutex` and `boost::unique_lock` with [`std::shared_mutex`](https://en.cppreference.com/w/cpp/thread/shared_mutex) & [`std::unique_lock`](https://en.cppreference.com/w/cpp/thread/unique_lock).
Even though [some concerns were raised](https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696) in #16684 with regard to `std::shared_mutex` being unsafe to use across some glibc versions, I still think this change is an improvement. As I mentioned in #21022, I also think trying to restrict standard library feature usage based on bugs in glibc is not only hard to do, but it's not currently clear exactly how we do that in practice (does it also extend to patching out use in our dependencies, should we be implementing more runtime checks for features we are using, when do we consider an affected glibc "old enough" not to worry about? etc). If you take a look through the [glibc bug tracker](https://sourceware.org/bugzilla/describecomponents.cgi?product=glibc) you'll no doubt find plenty of (active) bug reports for standard library code we already using. Obviously not to say we shouldn't try and avoid buggy code where possible.
Two other points:
[Cory mentioned in #21022](https://github.com/bitcoin/bitcoin/pull/21022#issuecomment-769274179):
> It also seems reasonable to me to worry that boost hits the same underlying glibc bug, and we've just not happened to trigger the right conditions yet.
Moving away from Boost to the standard library also removes the potential for differences related to Boosts configuration. Boost has multiple versions of `shared_mutex`, and what you end up using, and what it's backed by depends on:
* The version of Boost.
* The platform you're building for.
* Which version of `BOOST_THREAD_VERSION` is defined: (2,3,4 or 5) default=2. (see [here](https://www.boost.org/doc/libs/1_70_0/doc/html/thread/build.html#thread.build.configuration) for some of the differences).
* Is `BOOST_THREAD_V2_SHARED_MUTEX` defined? (not by default). If so, you might get the ["less performant, but more robust"](https://github.com/boostorg/thread/issues/230#issuecomment-475937761) version of `shared_mutex`.
A lot of these factors are eliminated by our use of depends, but users will have varying configurations. It's also not inconceivable to think that a distro, or some package manager might start defining something like `BOOST_THREAD_VERSION=3`. Boost tried to change the default from 2 to 3 at one point.
With this change, we no longer use Boost Thread, so this PR also removes it from depends, the build system, CI etc.
Previous similar PRs were #19183 & #20922. The authors are included in the commits here.
Also related to #21022 - pthread sanity checking.
ACKs for top commit:
laanwj:
Code review ACK 060a2a64d40d75fecb60b7d2b9946a67e46aa6fc
vasild:
ACK 060a2a64d40d75fecb60b7d2b9946a67e46aa6fc
Tree-SHA512: 572d14d8c9de20bc434511f20d3f431836393ff915b2fe9de5a47a02dca76805ad5c3fc4cceecb4cd43f3ba939a0508178c4e60e62abdbaaa6b3e8db20b75b03
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
doc: Changed miniupnp links to https
|
|
|
|
|
|
|
|
fa7789f7317229f7366f7a132df199e005ed3bc6 doc: Mention other ways to conserve memory on compilation (MarcoFalke)
Pull request description:
Related to:
* Building requires >1GB memory #6658
ACKs for top commit:
instagibbs:
ACK https://github.com/bitcoin/bitcoin/pull/16586/commits/fa7789f7317229f7366f7a132df199e005ed3bc6
kristapsk:
ACK fa7789f7317229f7366f7a132df199e005ed3bc6
Tree-SHA512: 828593de9cfa9f9027c6c8e97abe95e3fad9f2ff50e6512808a8950de4a1f9ea901e724edfb96d7119224c3e38a136e60cb798b34ef682c585a7951e02124a3a
|
|
|
|
|
|
|
|
|
|
|
|
fad95e8da6 doc: Split build linux dependencies (MarcoFalke)
0000009015 doc: Split depends installation instructions per arch (MarcoFalke)
Pull request description:
The current depends installation instructions fail on bionic with
```
E: Unable to locate package g++-4.8-aarch64-linux-gnu
E: Unable to locate package gcc-4.8-aarch64-linux-gnu
E: Unable to locate package g++-4.8-arm-linux-gnueabihf
E: Unable to locate package gcc-4.8-arm-linux-gnueabihf
```
Also, they fail due to missing dependencies `make automake cmake pkg-config python3`
Fix this by removing the explicit version and splitting them into common instructions and instructions per linux architecture.
Tree-SHA512: 25d5efa7450a0b1bbd569f431158f5a25bf4fe34f6adc32ebdfd6b6db9447ce083f555f20ff5b9f7c458864986c15d65219a31a1cd2b18bad9965ece2ea5e3be
|
|
autogen for the config files was missing.
|
|
|
|
functions
|
|
|
|
|
|
|
|
af6ac3b677454644364fd24d0df0c02ac9b8c8db doc: Remove mention of Qt4 from build docs (Wladimir J. van der Laan)
462c71f71b5d753bc8327ab833dea23679450ca3 test: Update travis to not test Qt4 anymore (Wladimir J. van der Laan)
907f73bbc5b6c98b01d7c6088a294dea66634a3f gui: Remove QT_VERSION fallbacks for Qt < 5 (Wladimir J. van der Laan)
bad068ad9f4bc60bfc10e27d4ffaec92d7df8491 build: Build system changes to support only Qt5 (Wladimir J. van der Laan)
Pull request description:
Implements #8263.
Qt4.x has been EOL since 2015, and at least Gentoo has, or is going to drop support for it. I wouldn't be surprised if other Linux distributions follow.
This removes Qt4 detection from the build system, as well as removes all Qt4 fallbacks from the code. Turns out there's more than I expected: this is going to make maintenance of the GUI code, as well as adding new features significantly easier.
(I know there's still some references left to qt4 in RPM and Debian build script, but I don't have the knowledge how to fix them)
Tree-SHA512: d495924fd4dda6f6566ba44ee96be7cbe62e69ba1ca993b80a8449f78da852b7f1bd3e8200d57cfa1d72233c340eeff4596fb0032ecbddc715d99aea63817d3f
|
|
|
|
|
|
docs: Linked to the 'Building on FreeBSD' section of the Unix guide where it lists BSD specific guides.
Created a FreeBSD build guide (doc/build-freebsd.md).
Added in warning about the version of 'gdb' installed by default.
Removed the FreeBSD build instructions now that they have their own guide (doc/build-freebsd.md).
Updated the sentence to refer to the BSD guides in the 'doc' directory for more specific BSD build instructions.
Minor grammatical fix.
|
|
The wallet part is described as optional, but apparently isn't
|
|
|
|
|
|
2712742 doc: Update FreeBSD build instructions to use bdb4 (Wladimir J. van der Laan)
d95c83d contrib: FreeBSD compatibility in install_db4.sh (Wladimir J. van der Laan)
c0298b0 contrib: Make X=Y arguments work in install_db4 (Wladimir J. van der Laan)
b798f9b contrib: New clang patch for install_db4 (Wladimir J. van der Laan)
Pull request description:
This PR improves the BSD compatibility of the bdb4 installer script.
See #11921, #11868.
I've tested this on OpenBSD 6.2 (clang) and Ubuntu 16.04 (gcc).
This needs testing on OSX at least, ~~and on gcc/Linux to make sure that applying the patch unconditionally doesn't negatively affect gcc~~.
~~NB: this is not yet sufficient to make `install_db4.sh` work on FreeBSD, as we need to use yet another `sha256` tool there. But it's a step in the right direction.~~
### contrib: New clang patch for install_db4
Replace the clang patch with a new and improved version that also fixes the build issues with OpenBSD and FreeBSD's clang, and apply it unconditionally.
Thanks to @fanquake for finding the patch.
### contrib: Make X=Y arguments work in install_db4
Trailing X=Y arguments are supposed to be passed through unchanged to bdb's configure. This was not the case, at least with OpenBSD 6.2's shell.
Fix this by not storing the arguments in a temporary variable but passing "$@" through directly.
### contrib: FreeBSD compatibility in install_db4.sh
Unfortunately, FreeBSD uses yet another syntax for `sha256`.
Support FreeBSD's syntax too. Using `uname` is a bit of a hack but it works and I found no way to distinguish the two.
Tree-SHA512: 12461a58dfeb4834701891762efc747c8187d834f41d98c8451edee1402a3958c4842bbc02c61bacbc7b0d90cc6b020a2ca158b65304d9760c9f0d2052ff36d4
|
|
Use Berkeley DB 4 as recommended on other platforms.
|
|
|
|
Instead of maintaining not-easily-tested instructions for building BerkeleyDB
in doc/build-unix.md, package the installation as a script in contrib/. This
allows shared usage from a number of contexts, e.g. Docker.
Thanks to @jonasschnelli, @laanwj for feedback.
|
|
e91b96192 Create dependencies.md, and link dependencies file from README & build docs (flack)
Pull request description:
As @fanquake mentioned in #8639, this should probably be a file in `doc/`, so I went ahead and pulled the issue text via the github API and dumped it into a file. No modifications made, except one spelling fix. This makes the info easier to find, and it will get a proper version history, too.
Tree-SHA512: 6ba4c37c97200972a74724e0e346d6ad5947c01ad18638e15250f2b4cd747dd744aba16e306c98d59f35736542a5eded7a17b6a5ce6aebc63c0a9dc969b365ef
|
|
|
|
python3 is required for running the unit tests on macOS, Ubuntu and Fedora.
Without python3 installed, 'make check' fails because /test/util/bitcoin-util-test.py fails to find python3.
|
|
- Package name is libevent, not libevent2
- Need to use GNU make
|
|
Re-try with most recent versions, and use BDB_CFLAGS/BDB_LIBS to
directly point at BerkeleyDB instead of CPPFLAGS hacks.
|
|
|
|
b55d823 Explicitly state that PPA is for Ubuntu only (anduck)
|
|
|