Cannot repair wheel ... libstd-xxx.so not found

[scanny]

I have a PyO3/maturin project that compiles, installs, and runs great on my Mac. I'm having trouble getting CI for it working with GitHub Actions. The maturin build step fails with:

    Finished `release` profile [optimized + debuginfo] target(s) in 22.95s
💥 maturin failed
  Caused by: Cannot repair wheel, because required library libstd-22be60875a4ac8d7.so could not be located.

I include the Finished release profile ... line because as far as I can tell the compile step succeeds.

I'm hoping someone can tell more from this message than I can and can point me in a fruitful direction.

Unfortunately the repo is private so I can't share it here.

I've minimized the GitHub workflow down to this. If I can get it to build in the CI environment I can attack other formats after. But essentially the target production environment is the same as this CI environment:

name: ci

on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      # -- checkout the repository --
      - name: Checkout code
        uses: actions/checkout@v4

      # - set up Python environment --
      - name: Set up Python 3.11
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      # -- Create virtual environment --
      - name: Create virtual environment
        run: python -m venv .venv

      # -- Install Python dependencies (maturin and pytest) --
      - name: Install Python dependencies
        run: |
          source .venv/bin/activate
          pip install maturin pytest

      # -- Build and install python-ppt --
      - name: Build and install Python extension
        run: |
          source .venv/bin/activate
          maturin build -vv --release -m abc_py/Cargo.toml

I've tried quite a few things, including using the PyO3/maturin action but the error is always the same.

I've tried the auto-generated CI script and some platforms hit this error (in particular linux x86_64 which is the one I need), and others don't. I've tried manylinux settings with no luck, installing the rust toolchain, rustup update, etc. with no change.

From my research it appears that libstd.so is the Rust standard library. Not sure what the hash between libstd- and .so means but that appears to change by platform but not between builds on the same platform.

Please ask if you need any further information and I'll be happy to provide it.

I'm very grateful for any direction you can provide as to how to understand what's happening and what direction to pursue to resolve it :)

[scanny]

Okay, I appear to have figured this out. Here are the high-points:

• libstd-22be60875a4ac8d7.so is indeed a Rust library, I assume the std portion. On the ubuntu-latest GitHub runner this lives at /home/runner/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/libstd-22be60875a4ac8d7.so. Note that no explicit installation of Rust is required, the runner comes with Rust already installed.
• I assume the 22be60875a4ac8d7 is a Rust-build specific hash/digest. It's different for amd64 for example but always the same between GitHub Action workflow runs for the same architecture.
• Adding this at the top of the maturin build ... step fixes the problem:

export LD_LIBRARY_PATH+=":$(rustc --print=sysroot)/lib"

I'm not sure why this is required and whether it is a bug or not, I assume it is not intended to be necessary because it is not part of the generated CI script and that script fails without this. Nor is it mentioned in any of the materials I've come across (and I've come across quite a few over the last day or so :).

I'll mention it in an issue in case it's something that needs fixing.

[messense]

Seems like you are linking Rust std dynamically which is odd because by default it should be linked statically, please check you build options like RUSTFLAGS etc.

[scanny]

@messense that was a very helpful pointer! I had this in .cargo/config.toml that I had copied fairly blindly somewhere along the (long) try-this/try-that journey:

# enable x86 optimizations V3
[target.x86_64-unknown-linux-gnu]
rustflags = "-C target-cpu=x86-64-v3 -C prefer-dynamic"

I got it from this repository that I had taken as something of an example: https://github.com/insight-platform/savant-rs/blob/main/.cargo/config.toml. I'm not sure why they would have that setting but I'm glad to know a little more about the difference now as I collect the puzzle pieces for my own mental model :)

In any case, when I comment that out I don't need the LD_LIBRARY_PATH line, so I expect that was at least one of the culprits. I know I had this problem before I put that in but I would have been better off to take it back out at the time I expect :)

Thanks for your help with this! I hope this discussion helps someone else who comes across the same problem later :)