sikkienl/dash
1
0
Fork 0
mirror of https://github.com/dashpay/dash.git synced 2024-12-27 04:52:59 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
46e527a550
dash/doc/build-unix.md
Wladimir J. van der Laan 0e8a4d54a4
Merge #21064: refactor: use std::shared_mutex & remove Boost Thread 
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
2024-01-16 09:29:52 -06:00

340 lines
11 KiB
Markdown
Raw Blame History

UNIX BUILD NOTES
====================
Some notes on how to build Dash Core in Unix.
(For BSD specific instructions, see `build-*bsd.md` in this directory.)
Note
---------------------
Always use absolute paths to configure and compile Dash Core and the dependencies.
For example, when specifying the path of the dependency:
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX
Here BDB_PREFIX must be an absolute path - it is defined using $(pwd) which ensures
the usage of the absolute path.
To Build
---------------------
```bash
./autogen.sh
./configure
make
make install # optional
```
This will build dash-qt as well, if the dependencies are met.
Dependencies
---------------------
These dependencies are required:
Library | Purpose | Description
------------|------------------|----------------------
libboost | Utility | Library for threading, data structures, etc
libevent | Networking | OS independent asynchronous networking
Optional dependencies:
Library | Purpose | Description
------------|------------------|----------------------
gmp | Optimized math routines | Arbitrary precision arithmetic library
miniupnpc | UPnP Support | Firewall-jumping support
libnatpmp | NAT-PMP Support | Firewall-jumping support
libdb4.8 | Berkeley DB | Wallet storage (only needed when wallet enabled)
qt | GUI | GUI toolkit (only needed when GUI enabled)
libqrencode | QR codes in GUI | Optional for generating QR codes (only needed when GUI enabled)
libzmq3 | ZMQ notification | Optional, allows generating ZMQ notifications (requires ZMQ version >= 4.0.0)
sqlite3 | SQLite DB | Wallet storage (only needed when wallet enabled)
For the versions used, see [dependencies.md](dependencies.md)
Memory Requirements
--------------------
C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of
memory available when compiling Dash Core. On systems with less, gcc can be
tuned to conserve memory with additional CXXFLAGS:
./configure CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768"
## Linux Distribution Specific Instructions
### Ubuntu & Debian
#### Dependency Build Instructions
Build requirements:
sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils bison python3
Now, you can either build from self-compiled [depends](/depends/README.md) or install the required dependencies:
sudo apt-get libevent-dev libboost-system-dev libboost-filesystem-dev libboost-test-dev
Berkeley DB is required for the wallet.
Ubuntu and Debian have their own `libdb-dev` and `libdb++-dev` packages, but these will install
Berkeley DB 5.1 or later. This will break binary wallet compatibility with the distributed executables, which
are based on BerkeleyDB 4.8. If you do not care about wallet compatibility,
pass `--with-incompatible-bdb` to configure.
Otherwise, you can build Berkeley DB [yourself](#berkeley-db).
SQLite is required for the wallet:
sudo apt install libsqlite3-dev
To build Dash Core without wallet, see [*Disable-wallet mode*](#disable-wallet-mode)
Optional port mapping libraries (see: `--with-miniupnpc` and `--with-natpmp`):
sudo apt install libminiupnpc-dev libnatpmp-dev
ZMQ dependencies (provides ZMQ API):
sudo apt-get install libzmq3-dev
GMP dependencies (provides platform-optimized routines):
sudo apt-get install libgmp-dev
GUI dependencies:
If you want to build dash-qt, make sure that the required packages for Qt development
are installed. Qt 5 is necessary to build the GUI.
To build without GUI pass `--without-gui`.
To build with Qt 5 you need the following:
sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools
Additionally, to support Wayland protocol for modern desktop environments:
sudo apt install qtwayland5
libqrencode (optional) can be installed with:
sudo apt-get install libqrencode-dev
Once these are installed, they will be found by configure and a dash-qt executable will be
built by default.
### Fedora
#### Dependency Build Instructions
Build requirements:
sudo dnf install gcc-c++ libtool make autoconf automake python3
Now, you can either build from self-compiled [depends](/depends/README.md) or install the required dependencies:
sudo dnf install libevent-devel boost-devel
Berkeley DB is required for the wallet:
sudo dnf install libdb4-devel libdb4-cxx-devel
Newer Fedora releases, since Fedora 33, have only `libdb-devel` and `libdb-cxx-devel` packages, but these will install
Berkeley DB 5.3 or later. This will break binary wallet compatibility with the distributed executables, which
are based on Berkeley DB 4.8. If you do not care about wallet compatibility,
pass `--with-incompatible-bdb` to configure.
Otherwise, you can build Berkeley DB [yourself](#berkeley-db).
SQLite is required for the wallet:
sudo dnf install sqlite-devel
To build Dash Core without wallet, see [*Disable-wallet mode*](#disable-wallet-mode)
Optional port mapping libraries (see: `--with-miniupnpc` and `--with-natpmp`):
sudo dnf install miniupnpc-devel libnatpmp-devel
ZMQ dependencies (provides ZMQ API):
sudo dnf install zeromq-devel
GMP dependencies (provides platform-optimized routines):
sudo dnf install gmp-devel
GUI dependencies:
If you want to build dash-qt, make sure that the required packages for Qt development
are installed. Qt 5 is necessary to build the GUI.
To build without GUI pass `--without-gui`.
To build with Qt 5 you need the following:
sudo dnf install qt5-qttools-devel qt5-qtbase-devel
Additionally, to support Wayland protocol for modern desktop environments:
sudo dnf install qt5-qtwayland
libqrencode (optional) can be installed with:
sudo dnf install qrencode-devel
Once these are installed, they will be found by configure and a dash-qt executable will be
built by default.
Notes
-----
The release is built with GCC and then "strip dashd" to strip the debug
symbols, which reduces the executable size by about 90%.
miniupnpc
---------
[miniupnpc](https://miniupnp.tuxfamily.org) may be used for UPnP port mapping. It can be downloaded from [here](
https://miniupnp.tuxfamily.org/files/). UPnP support is compiled in and
turned off by default.
libnatpmp
---------
[libnatpmp](https://miniupnp.tuxfamily.org/libnatpmp.html) may be used for NAT-PMP port mapping. It can be downloaded
from [here](https://miniupnp.tuxfamily.org/files/). NAT-PMP support is compiled in and
turned off by default.
Berkeley DB
-----------
It is recommended to use Berkeley DB 4.8. If you have to build it yourself,
you can use [the installation script included in contrib/](contrib/install_db4.sh)
like so:
```shell
./contrib/install_db4.sh `pwd`
```
from the root of the repository.
Otherwise, you can build Dash Core from self-compiled [depends](/depends/README.md).
**Note**: You only need Berkeley DB if the wallet is enabled (see [*Disable-wallet mode*](#disable-wallet-mode)).
Boost
-----
If you need to build Boost yourself:
sudo su
./bootstrap.sh
./bjam install
Security
--------
To help make your Dash Core installation more secure by making certain attacks impossible to
exploit even if a vulnerability is found, binaries are hardened by default.
This can be disabled with:
Hardening Flags:
./configure --enable-hardening
./configure --disable-hardening
Hardening enables the following features:
* _Position Independent Executable_: Build position independent code to take advantage of Address Space Layout Randomization
offered by some kernels. Attackers who can cause execution of code at an arbitrary memory
location are thwarted if they don't know where anything useful is located.
The stack and heap are randomly located by default, but this allows the code section to be
randomly located as well.
On an AMD64 processor where a library was not compiled with -fPIC, this will cause an error
such as: "relocation R_X86_64_32 against `......' can not be used when making a shared object;"
To test that you have built PIE executable, install scanelf, part of paxutils, and use:
scanelf -e ./dashd
The output should contain:
TYPE
ET_DYN
* _Non-executable Stack_: If the stack is executable then trivial stack-based buffer overflow exploits are possible if
vulnerable buffers are found. By default, Dash Core should be built with a non-executable stack,
but if one of the libraries it uses asks for an executable stack or someone makes a mistake
and uses a compiler extension which requires an executable stack, it will silently build an
executable without the non-executable stack protection.
To verify that the stack is non-executable after compiling use:
`scanelf -e ./dashd`
The output should contain:
STK/REL/PTL
RW- R-- RW-
The STK RW- means that the stack is readable and writeable but not executable.
Disable-wallet mode
--------------------
When the intention is to run only a P2P node without a wallet, Dash Core may be compiled in
disable-wallet mode with:
./configure --disable-wallet
In this case there is no dependency on Berkeley DB 4.8 and SQLite.
Mining is also possible in disable-wallet mode using the `getblocktemplate` RPC call.
Additional Configure Flags
--------------------------
A list of additional configure flags can be displayed with:
./configure --help
Setup and Build Example: Arch Linux
-----------------------------------
This example lists the steps necessary to setup and build a command line only, non-wallet distribution of the latest changes on Arch Linux:
pacman -S git base-devel boost libevent python
git clone https://github.com/dashpay/dash.git
cd dash/
./autogen.sh
./configure --disable-wallet --without-gui --without-miniupnpc
make check
Note:
Enabling wallet support requires either compiling against a Berkeley DB newer than 4.8 (package `db`) using `--with-incompatible-bdb`,
or building and depending on a local version of Berkeley DB 4.8. The readily available Arch Linux packages are currently built using
`--with-incompatible-bdb` according to the [PKGBUILD](https://projects.archlinux.org/svntogit/community.git/tree/bitcoin/trunk/PKGBUILD).
As mentioned above, when maintaining portability of the wallet between the standard Dash Core distributions and independently built
node software is desired, Berkeley DB 4.8 must be used.
ARM Cross-compilation
-------------------
These steps can be performed on, for example, an Ubuntu VM. The depends system
will also work on other Linux distributions, however the commands for
installing the toolchain will be different.
Make sure you install the build requirements mentioned above.
Then, install the toolchain and curl:
sudo apt-get install g++-arm-linux-gnueabihf curl
To build executables for ARM:
cd depends
make HOST=arm-linux-gnueabihf NO_QT=1
cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/arm-linux-gnueabihf/share/config.site ./configure --enable-reduce-exports LDFLAGS=-static-libstdc++
make
For further documentation on the depends system see [README.md](../depends/README.md) in the depends directory.
Reference in New Issue View Git Blame Copy Permalink