Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build windows dll from vendored source code #44

Closed
arnetheduck opened this issue Jun 4, 2024 · 0 comments
Closed

Build windows dll from vendored source code #44

arnetheduck opened this issue Jun 4, 2024 · 0 comments
Assignees

Comments

@arnetheduck
Copy link
Member

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.

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).
@web3-developer web3-developer self-assigned this Jun 4, 2024
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants