The `rocksdb` version shipped with distributions is typically old and
therefore often lacks features we use - it also doesn't match the one
assumed by nim-rocksdb leading to ABI mismatch risks.
Instead of depending on the system rocksdb, we'll now use the rocksdb
version assumed by nim-rocksdb and locked in its vendor folder by always
building it together with nimbus.
This avoids the problem of unknown rocksdb versions at a (small) cost to
build time.
CI caching and full windows support for building from source [remains
TODO](https://github.com/status-im/nim-rocksdb/issues/44).
* Static link rocksdb into Nimbus.
* Link in additional compression libraries.
* Support static linking for MacOS.
* Add flag to support disabling rocksdb static linking.
* Static linking is disabled by default. Build nimbus with static linking using: make nimbus_rocksdb_static
* Update nim-rocksdb to latest.
In preparation of our migration to the new Nimble-based setup
and [nim-workspace][1], we switch to a new model where the vendor
packages are no longer imported through a locally generated Nimble
dir, but rather through an auto-generated `nimbus-build-system.paths`
file that features regular `--path:` statements.
This file will be imported only within the nimbus-build-system
environment in order to avoid any unwanted interference in working
copies based on the new Nimble setup.
[1]: https://github.com/status-im/nim-workspace
* dist: precompiled binaries and Docker images
The builds are reproducible, the binaries are portable and statically link librocksdb.
This took some patching. Upstream PR: https://github.com/facebook/rocksdb/pull/9752
32-bit ARM is missing as a target because two different GCC versions
fail with an ICE when trying to cross-compile RocksDB. Using Clang
instead is too much trouble for a platform that nobody should be using
anyway.
(Clang doesn't come with its own target headers and libraries, can't be
easily convinced to use the ones from GCC, so it needs an fs image from
a 32-bit ARM distro - at which point I stopped caring).
* CI: disable reproducibility test
We can't use `ulimit -s` to limit stack size on Windows. Even though Bash
accepts `ulimit -s` and the numbers change it has no effect and is not passed
to child processes.
(See https://public-inbox.org/git/alpine.DEB.2.21.1.1709131448390.4132@virtualbox/)
Instead, set it when building the test executable, following, a suggestion from
@stefantalpalaru.
https://github.com/status-im/nimbus-eth1/pull/598#discussion_r621107128
To ensure no conflict with `config.nims`, `-d:windowsNoSetStack` is used. This
proved unnecessary in practice because the command-line option is passed to the
linker after the config file option. But given we don't have an automated test
to verify linker behaviour, it's best not to rely on the option order, neither
how the linker treats it, or whether Nim will always send them in that order.
Testing:
This has been verified by using a smaller limit. At 200k, all `ENABLE_EVMC=0`
OS targets passed as expected, and all `ENABLE_EVMC=1` OS targets failed with
expected kinds of errors due to stack overflow, including Windows.
(400k wasn't small enough; 32-bit x86 Windows passed on that).
Signed-off-by: Jamie Lokier <jamie@shareable.org>
* switch to chronos metrics, remove insecure
See https://github.com/status-im/nimbus-eth2/pull/2468
also fixes pcre linking for real, and adds some random build flags that
help nimbus-eth2 stay afloat
* fix help
* don't omit frame pointers on windows
* bump vendor/nimbus-build-system
- add the Nim compiler header to the Nimbus header
- also support the USE_LIBBACKTRACE env var
* "go-checks" target no longer available
Jacek Sieka
tersec
web3-developer
andri lim
Kim De Mey
Zahary Karadjov
Ștefan Talpalaru
Zahary Karadjov
Jamie Lokier