You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #40, support for building a statically linked rocksdb was added.
Arguably the most important benefit of this approach is that the version of rocksdb used by the application matches the ABI described in this library, ie that the nim ABI matches the compiled library.
Since building a static rocksdb library on windows is difficult, the second-best option is to build a DLL from the vendored source code and build that the same way that the static files are being built - then applications like nimbus can simply build the dll on windows and a static library on mac/linux.
Moving that build into this repository will conveniently remove the dependency on nimbus-deps completely, which will simplify the build, CI and distribution for all nim-rocksdb users.
It will also ensure that we build rocksdb with the same options (zstd, lz4) on all platforms, and that when we upgrade the submodule here, those upgrades are propagated to users.
The text was updated successfully, but these errors were encountered:
arnetheduck
added a commit
to status-im/nimbus-eth1
that referenced
this issue
Jun 4, 2024
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](status-im/nim-rocksdb#44).
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](status-im/nim-rocksdb#44).
In #40, support for building a statically linked rocksdb was added.
Arguably the most important benefit of this approach is that the version of rocksdb used by the application matches the ABI described in this library, ie that the nim ABI matches the compiled library.
Since building a static rocksdb library on windows is difficult, the second-best option is to build a DLL from the vendored source code and build that the same way that the static files are being built - then applications like nimbus can simply build the dll on windows and a static library on mac/linux.
The windows version of the dll was recently updated here: status-im/nimbus-deps#2
Moving that build into this repository will conveniently remove the dependency on nimbus-deps completely, which will simplify the build, CI and distribution for all nim-rocksdb users.
It will also ensure that we build rocksdb with the same options (zstd, lz4) on all platforms, and that when we upgrade the submodule here, those upgrades are propagated to users.
The text was updated successfully, but these errors were encountered: