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.

Sign up for GitHub

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

Jump to bottom

Old mdbx-sys starting to become an issue on fresh/newer linux installs #4354

Closed
DaveWK opened this issue May 30, 2023 · 3 comments
Closed

Old mdbx-sys starting to become an issue on fresh/newer linux installs #4354

DaveWK opened this issue May 30, 2023 · 3 comments

Comments

@DaveWK
Copy link

DaveWK commented May 30, 2023

Description

I noticed that on some of my fresh linux installs that the old version of mdbx-sys that is included by default no longer compiles correctly.. In the build logs I see:

```error: failed to run custom build command for mdbx-sys v0.11.6-4 (https://github.com/sigp/libmdbx-rs?tag=v0.1.4#096da80a)

Caused by:
process didn't exit successfully: /opt/src/lighthouse/target/maxperf/build/mdbx-sys-c3a9ecd0986e3970/build-script-build (exit status: 101)
--- stderr
thread 'main' panicked at '"MDBX_version_info_struct_(unnamed_at_/root/_cargo/git/checkouts/libmdbx-rs-c1b523f5b64ff08c/096da80/mdbx-sys/libmdbx/mdbx_h_611_3)" is not a valid Ident', /root/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/proc-macro2-1.0.58/src/fallback.rs:811:9
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...```

I believe this is due to more recent linux builds using a newer glibc version. I can work around this by doing:

CARGO_INSTALL_EXTRA_FLAGS="--no-default-features" FEATURES=slasher-lmdb,modern,jemalloc PROFILE=maxperf make

but wanted you to be aware that this was occurring. It seems like there's been some updates to mdbx (which still claims to support windows on newer versions?)

Version

Any/all
@michaelsproul
Copy link
Member

Thanks, we're aware of the issue. I've been mulling over the best way to deal with it. I think we have 2 options:

  1. Deprecate MDBX and avoid building it by default. We can switch back to LMDB by default.
  2. Update the MDBX bindings, possibly using work from the Reth devs (fix: update bindgen in libmdbx-rs paradigmxyz/reth#2703). This would retain Windows support and improve Linux distro compatibility. The note in our docs about Windows support being removed upstream was mostly to do with the old MBDX Rust bindings (from which Windows support was deleted), and statements from the MDBX author which I think he's now gone back on.

Option 1 would also remove the need for #4305 or #4305.

I have a slight preference for Option 1, because I'm personally sick of dealing with MDBX-related issues. But perhaps the pragmatic solution is Option 2 (or a combination of updating MDBX and deprecating it).

@DaveWK
Copy link
Author

DaveWK commented May 31, 2023

Not sure if this is helpful or not , but did noticed this repo seems to be keeping up w/ the lmdbx revs: https://github.com/vorot93/libmdbx-rs and according to #7 on the doc, it still has windows support: https://libmdbx.dqdkfa.ru/

@michaelsproul
Copy link
Member

Those are the bindings we used to use. I added Windows to support to them, and Artem deleted the support in this commit vorot93/libmdbx-rs@bd749c2.

@michaelsproul michaelsproul mentioned this issue Jun 1, 2023
Closed
bors bot pushed a commit that referenced this issue Jun 7, 2023
@michaelsproul
Switch default slasher backend to LMDB (#4360)
da14114 
## Issue Addressed

Closes #4354
Closes #3987

Replaces #4305, #4283

## Proposed Changes

This switches the default slasher backend _back_ to LMDB.

If an MDBX database exists and the MDBX backend is enabled then MDBX will continue to be used. Our release binaries and Docker images will continue to include MDBX for as long as it is practical, so users of these should not notice any difference.

The main benefit is to users compiling from source and devs running tests. These users no longer have to struggle to compile MDBX and deal with the compatibility issues that arises. Similarly, devs don't need to worry about toggling feature flags in tests or risk forgetting to run the slasher tests due to backend issues.
bors bot pushed a commit that referenced this issue Jun 7, 2023
@michaelsproul
Switch default slasher backend to LMDB (#4360)
f3dcb8b 
## Issue Addressed

Closes #4354
Closes #3987

Replaces #4305, #4283

## Proposed Changes

This switches the default slasher backend _back_ to LMDB.

If an MDBX database exists and the MDBX backend is enabled then MDBX will continue to be used. Our release binaries and Docker images will continue to include MDBX for as long as it is practical, so users of these should not notice any difference.

The main benefit is to users compiling from source and devs running tests. These users no longer have to struggle to compile MDBX and deal with the compatibility issues that arises. Similarly, devs don't need to worry about toggling feature flags in tests or risk forgetting to run the slasher tests due to backend issues.
ghost pushed a commit to oone-world/lighthouse that referenced this issue Jul 13, 2023
@michaelsproul
Switch default slasher backend to LMDB (sigp#4360)
cc13f60 
## Issue Addressed

Closes sigp#4354
Closes sigp#3987

Replaces sigp#4305, sigp#4283

## Proposed Changes

This switches the default slasher backend _back_ to LMDB.

If an MDBX database exists and the MDBX backend is enabled then MDBX will continue to be used. Our release binaries and Docker images will continue to include MDBX for as long as it is practical, so users of these should not notice any difference.

The main benefit is to users compiling from source and devs running tests. These users no longer have to struggle to compile MDBX and deal with the compatibility issues that arises. Similarly, devs don't need to worry about toggling feature flags in tests or risk forgetting to run the slasher tests due to backend issues.
Woodpile37 pushed a commit to Woodpile37/lighthouse that referenced this issue Jan 6, 2024
@michaelsproul @Woodpile37
Switch default slasher backend to LMDB (sigp#4360)
4a68be4 
## Issue Addressed

Closes sigp#4354
Closes sigp#3987

Replaces sigp#4305, sigp#4283

## Proposed Changes

This switches the default slasher backend _back_ to LMDB.

If an MDBX database exists and the MDBX backend is enabled then MDBX will continue to be used. Our release binaries and Docker images will continue to include MDBX for as long as it is practical, so users of these should not notice any difference.

The main benefit is to users compiling from source and devs running tests. These users no longer have to struggle to compile MDBX and deal with the compatibility issues that arises. Similarly, devs don't need to worry about toggling feature flags in tests or risk forgetting to run the slasher tests due to backend issues.
Woodpile37 pushed a commit to Woodpile37/lighthouse that referenced this issue Jan 6, 2024
@michaelsproul @Woodpile37
Switch default slasher backend to LMDB (sigp#4360)
71fda69 
## Issue Addressed

Closes sigp#4354
Closes sigp#3987

Replaces sigp#4305, sigp#4283

## Proposed Changes

This switches the default slasher backend _back_ to LMDB.

If an MDBX database exists and the MDBX backend is enabled then MDBX will continue to be used. Our release binaries and Docker images will continue to include MDBX for as long as it is practical, so users of these should not notice any difference.

The main benefit is to users compiling from source and devs running tests. These users no longer have to struggle to compile MDBX and deal with the compatibility issues that arises. Similarly, devs don't need to worry about toggling feature flags in tests or risk forgetting to run the slasher tests due to backend issues.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@michaelsproul @DaveWK