solc-select fails on Linux ARM64/aarch64 systems (Docker on Apple Silicon, AWS Graviton, etc.)

[dguido]

Description

solc-select does not support Linux ARM64/aarch64 architecture, causing failures when running on ARM-based Linux systems. This affects Docker containers on Apple Silicon Macs, AWS Graviton instances, Raspberry Pi, and other ARM64 Linux environments.

Current Behavior

On Linux ARM64 systems, solc-select:

1. Incorrectly identifies the system as linux-amd64
2. Downloads x86_64 binaries that cannot execute on ARM64
3. Fails with "cannot execute binary file: Exec format error"

Steps to Reproduce

1. Run on any Linux ARM64 system (e.g., Docker on M1/M2 Mac):

docker run --platform linux/arm64 -it python:3.11 bash
pip install solc-select
solc-select install 0.8.19
solc-select use 0.8.19
solc --version
# Error: cannot execute binary file: Exec format error

2. Check what solc-select downloaded:

file ~/.solc-select/artifacts/solc-0.8.19/solc-0.8.19
# ELF 64-bit LSB executable, x86-64 (wrong architecture!)

Expected Behavior

solc-select should either:

• Support ARM64 Linux with appropriate binaries
• Provide a clear error message about unsupported architecture
• Offer a fallback solution (e.g., using WASM binaries)

Root Cause

The soliditylang_platform() function in solc_select/solc_select.py:275-284 only checks the OS, not the architecture:

def soliditylang_platform() -> str:
    if sys.platform.startswith("linux"):
        platform = LINUX_AMD64  # Always returns AMD64 for any Linux!
    elif sys.platform == "darwin":
        platform = MACOSX_AMD64
    # ...

System Information

• Python version: 3.11
• solc-select version: 1.0.4
• Architecture: aarch64 / arm64 (from platform.machine())
• OS: Linux
• Common environments: Docker on Apple Silicon, AWS Graviton, native ARM64 Linux

Impact

This affects all tools that depend on solc-select:

• Manticore: Ethereum analysis fails on ARM64
• Slither: Cannot analyze Solidity contracts
• Echidna: Fuzzing unavailable on ARM64 systems
• Development workflows: Docker-based development on Apple Silicon Macs
• CI/CD: GitHub Actions on ARM64 runners, AWS Graviton-based CI

Proposed Solutions

Option 1: WASM/emscripten fallback (Recommended)

• Use existing emscripten-wasm32 binaries from binaries.soliditylang.org
• These work on any architecture via Node.js
• Similar to how npm install solc works cross-platform

Option 2: Architecture detection + clear errors

• Properly detect ARM64: platform.machine() in ["aarch64", "arm64"]
• Provide informative error with workarounds
• Document QEMU or other solutions

Option 3: Native ARM64 binaries

• Build and host ARM64 Linux binaries (like Crytic does for old versions)
• Higher maintenance but best performance

Workarounds

Current workarounds for users:

1. Use npm install -g solc instead (requires Node.js)
2. Install QEMU for x86_64 emulation
3. Use x86_64 Docker platform: --platform linux/amd64

Additional Context

• The Solidity team doesn't provide official Linux ARM64 binaries
• macOS already has architecture handling (Rosetta detection, Universal binary support)
• Available platforms at binaries.soliditylang.org: linux-amd64, macosx-amd64, windows-amd64, emscripten-wasm32, emscripten-asmjs
• No linux-arm64 or linux-aarch64 directories exist

Related Code

For reference, macOS already handles architecture differences:

• solc_select/utils.py:mac_can_run_intel_binaries() - Detects Rosetta
• solc_select/utils.py:mac_binary_is_universal() - Checks for Universal binaries

A similar approach could work for Linux ARM64.

---

Would the maintainers be open to a PR implementing WASM fallback support for ARM64 Linux? This would provide immediate cross-architecture compatibility while maintaining the same user interface.