Remove redundant libstdc++6 installation

[masih]

Ubuntu 24.04’s runtime image already includes a distro-provided libstdc++6 with GLIBCXX_3.4.32 support. Remove the redundant explicit installation while retaining CA certificate setup.

[cursor]

PR Summary

Low Risk
Single-package removal from the runtime Dockerfile with no application logic changes; risk is limited to a possible runtime link failure if base-image libstdc++ were insufficient for bundled native libs.

Overview
Runtime image no longer runs apt-get install libstdc++6 in the Ubuntu 24.04 final stage; only ca-certificates is installed explicitly.

Native libraries (*.so from the builder, including wasm/evmone) are still copied to /usr/lib and the rest of the Dockerfile is unchanged. The change assumes the base image’s bundled libstdc++6 is sufficient for those binaries at runtime.

^{Reviewed by Cursor Bugbot for commit 2b9f025. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Aug 4, 2026, 10:17 AM

[seidroid]

One-line Dockerfile change removing the redundant explicit libstdc++6 install; I confirmed the pinned ubuntu:24.04 base already provides libstdc++6 at GLIBCXX_3.4.33 while the vendored libevmone libs need at most GLIBCXX_3.4.32, so the removal is safe. No blockers — only a maintainability note that the dependency is now implicit and PR CI builds but never runs the image.

Findings: 0 blocking | 3 non-blocking | 1 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• PR CI only runs docker build for the root Dockerfile (.github/workflows/docker_build.yml:54); the image is never executed, and the integration-test workflow builds docker/localnode/docker/rpcnode instead. A missing runtime shared-library dependency therefore fails at container start, not in CI. Consider adding a cheap smoke step (e.g. docker run --rm <built image> version) so the runtime link of /usr/lib/libevmone*.so is actually exercised.
• Cursor's second-opinion review file (cursor-review.md) was empty — that pass produced no output. Codex reported no material issues, consistent with this review.
• 1 suggestion(s)/nit(s) flagged inline on specific lines.

[seidroid]

[suggestion] Verified this is safe for the pinned base: the vendored libevmone libs copied in at line 56 require libstdc++.so.6 with at most GLIBCXX_3.4.32 / CXXABI_1.3.9, and ubuntu:24.04 ships libstdc++6 (GCC 13/14, GLIBCXX_3.4.32+) unconditionally because apt itself depends on it.

The caveat is that the dependency is now satisfied only transitively by the base layer rather than declared. If the base is ever swapped for a slim/-minimal/distroless variant (or a digest whose apt no longer pulls libstdc++6), seid will fail at container start with a dlopen/GLIBCXX error that docker build won't catch. Suggest a short comment here recording that libevmone needs the base image's libstdc++6 (>= GLIBCXX_3.4.32), so a future base-image change gets the right prompt.

[claude]

LGTM — trivial Dockerfile cleanup.

Extended reasoning...

Overview

The PR removes the explicit libstdc++6 apt-get install from the final Ubuntu 24.04 runtime stage of the Dockerfile, keeping ca-certificates. The stated rationale is that Ubuntu 24.04's base image already ships libstdc++6 with GLIBCXX_3.4.32, so the explicit install is redundant. This claim is plausible — libstdc++6 is a near-universal base dependency in Debian/Ubuntu images (pulled in transitively by base-files/coreutils tooling), and Ubuntu 24.04 in particular ships a glibc/gcc-13 toolchain with GLIBCXX_3.4.32 already available.

Security risks

None. This only removes a package installation; it does not add any new dependency, open any port, or change any credential/permission handling.

Level of scrutiny

Low. This is a one-line Dockerfile change in a non-critical build/packaging path (not consensus, state machine, or RPC code). The change is easily verified by building the image and confirming the seid binary (which dynamically links libwasmvm/libevmone .so files that depend on libstdc++) still runs — a straightforward smoke test that CI/release pipelines will naturally exercise on the next build.

Other factors

Single file, single line changed, no logic/behavior change to the application itself, and it carries a backport label (release/v6.6) suggesting it's already been reasoned about for the target release. No repo-specific upgrade-gate or config-read concerns apply here.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.68%. Comparing base (e34c457) to head (2b9f025).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3847      +/-   ##
==========================================
- Coverage   61.54%   60.68%   -0.86%     
==========================================
  Files        2361     2269      -92     
  Lines      199417   188911   -10506     
==========================================
- Hits       122723   114634    -8089     
+ Misses      65739    64175    -1564     
+ Partials    10955    10102     -853     

Flag	Coverage Δ
sei-db	70.41% <ø> (ø)
sei-db-state-db	?

Flags with carried forward coverage won't be shown. Click here to find out more.
see 92 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[seidroid]

Successfully created backport PR for release/v6.6:

• Backport release/v6.6: Remove redundant libstdc++6 installation #3848