Age | Commit message (Collapse) | Author |
|
Our compile documentation isn't the right place for genric binary
hardening notes, which are neither particularly Bitcoin-Core specific,
or as relevant as they might have once been, i.e non-executable stacks
are now just the norm.
Just remove the notes for now, if someone has
something more interesting/Bitcoin Core specific, it could be added in
separate documentation in the future (maybe into the devwiki or
similar).
Split from
https://github.com/bitcoin/bitcoin/pull/27685#discussion_r1196517868.
|
|
|
|
|
|
|
|
Now that we can build a bdb-only depends prefix, there is no need to
maintain a bdb-building bash script, that does the same things as
depends, except worse, as it's missing patches and workarounds. i.e #26623.
|
|
No reason to have this here with outdated information. We already point
users to the depends readme, the doc cross builders should be pointed to
, within this doc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Calling dependencies optional in a list of already optional dependencies
is redundant.
|
|
We don't do this for any other dependency, and users are better looking
at the actual Boost site/docs. This isn't something we should need to
have in our build docs.
|
|
build-unix.md
78e36700a0b42f558af2be567eab9fbf6c9ef0b1 doc: remove mention of system univalue (fanquake)
Pull request description:
Should have been part of #22646.
ACKs for top commit:
hebasto:
ACK 78e36700a0b42f558af2be567eab9fbf6c9ef0b1
Tree-SHA512: a5d54d73526033825ce4467cc3c57c26064739eef546556975a4c6f1f5bea84004640acd426734f90f98bc7a76ec837d716aa31167f2bdce7ee3887ad92e3152
|
|
Should have been part of #22646.
|
|
This updates build-unix for the descriptor wallet, and prepares for
eventual legacy wallet deprecation.
- Move 'descriptor wallet' dependencies above legacy wallet deps both
for Debian and Fedora.
- Explicitly mention 'legacy wallet' where referring to the BerkeleyDB
wallet. Shorten BerkeleyDB instruction to a single paragraph.
|
|
|
|
|
|
|
|
|
|
|
|
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
|