Installed binary fails due to glibc version

[ColonelJ]

Tried installing on Ubuntu 18.04 following the instructions for heliosup, but attempting to run the resulting helios binary faced with the following errors:

helios: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by helios)
helios: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by helios)

(Ubuntu 18.04 has glibc 2.27.)

Normally this would happen because the build was performed on a newer operating system. Building on an old one should give better compatibility. Alternatively, statically linking a libc (by targeting musl) would avoid this issue.

[ncitron]

Thanks for the report. I'll do some research to see which of these options is best compatibility-wise.

[payton]

@ncitron I may have a similar issue on Ubuntu 20.04 (w/ glibc 2.31) as glibc is the last on the trace.

Getting the following when trying to cargo build. I'm able to build successfully on my mac.

I am able to install/run both with heliosup, though.

thread '<unnamed>' panicked at 'forcing query with already existing `DepNode`
- query-key: Canonical { max_universe: U0, variables: [CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Region(U0) }], value: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [Binder(OutlivesPredicate(ReLateBound(DebruijnIndex(1), BoundRegion { var: 0, kind: BrAnon(0, None) }), ReLateBound(DebruijnIndex(1), BoundRegion { var: 1, kind: BrAnon(1, None) })), []), Binder(OutlivesPredicate(rpc::RpcInner, ReLateBound(DebruijnIndex(1), BoundRegion { var: 1, kind: BrAnon(1, None) })), [])], reveal: UserFacing, constness: NotConst }, value: Binder(TraitPredicate(<for<'a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i> {std::future::ResumeTy, &'a mut execution::evm::Evm<'b, execution::rpc::http_rpc::HttpRpc>, &'c execution::types::CallOpts, &'d execution::evm::Evm<'e, execution::rpc::http_rpc::HttpRpc>, impl std::future::Future<Output = std::result::Result<std::collections::HashMap<ethers::types::H160, execution::types::Account>, eyre::Report>>, ()} as std::marker::Send>, polarity:Positive), []) } }
- dep-node: evaluate_obligation(cfcb6a704d6313dd-ee134d32e1fb2d71)', /rustc/6284998a2677d7e3e8420db783f3aa4fd80d7423/compiler/rustc_query_system/src/dep_graph/graph.rs:316:9
stack backtrace:
   0:     0x7f3d1e587440 - std::backtrace_rs::backtrace::libunwind::trace::h158b1ea709fc4e63
                               at /rustc/6284998a2677d7e3e8420db783f3aa4fd80d7423/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x7f3d1e587440 - std::backtrace_rs::backtrace::trace_unsynchronized::h9ddac896e1f23a6d
                               at /rustc/6284998a2677d7e3e8420db783f3aa4fd80d7423/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
...
                               at /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477:8
  44:     0x7f3d1e36b133 - clone
                               at /build/glibc-SzIz7B/glibc-2.31/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  45:                0x0 - <unknown>
warning: `client` (lib) generated 1 warning
error: could not compile `client`; 1 warning emitted

[gakonst]

foundry-rs/foundry#825 https://github.com/foundry-rs/foundry/pull/826/files maybe relevant

[ncitron]

Thanks for the tip @gakonst.

@payton the issue you are running into when building from source was due to a bug that briefly existed in the rust nightly build last week. Running rustup then building again should resolve that issue.

I will also be updating heliosup to make installing and building from source a bit easier.

[AustinFoss]

Hello, been combing through the issues a bit while trying to get a webassembly instance working in the browser but found #226 and doesn't seem to be 100% possible yet.

While going through my initial setup, prior to hitting the tokio blocker, I had the same experience as described above. My remote VPS was running Debian Bullseye and was locked to version 2.31 of libc6: https://packages.debian.org/search?keywords=libc6

I modified my apt sources list convert my distro from bullseye to debian testing (bookworm) and it's fixed. This forum thread on Ubuntu provides some added info as well: https://askubuntu.com/questions/1334633/mainline-kernel-now-depends-on-libc6-2-33-non-installable-in-focal

Seems any distro based on the former LTS release, 20.04 is just not compatible and you need to use a distro with a recent enough kernel. On 22.04 if you install libc6 you get version 2.35: https://packages.ubuntu.com/search?keywords=libc6&searchon=names&suite=jammy&section=all

Hope this helps give context. Seems that it's just a matter of older distro's trying to run this.