Can't find libgcc_s.so due to incorrect RPATH in musllinux wheel

[matt-codecov]

Bug Description

v1.7.2 is creating wheels that fail to load libgcc_s.so with an error message like this:

E   ImportError: Error loading shared library libgcc_s-1e52349c.so.1: No such file or directory (needed by /io/.venv/lib/python3.12/site-packages/codecov_rs/_bindings.abi3.so)

(job link) (download wheel)

Downgrading to v1.7.1 in the maturin action fixes the problem. (job link, download wheel)

Both wheels have the same file structure with relevant files:

• codecov_rs/_bindings.abi3.so
• codecov_rs.libs/libgcc_s-1e52349c.so.1

The problem is shown with objdump -p:

# The working wheel looks for `codecov_rs.libs` in the right place
$ objdump -p v1.7.1/codecov_rs/_bindings.abi3.so
...
Dynamic Section:
  RPATH        $ORIGIN/../codecov_rs.libs
  NEEDED       libgcc_s-1e52349c.so.1
  NEEDED       libc.so
  SONAME       lib_bindings.so
...

# The broken wheel looks one directory too high
$ objdump -p v1.7.2/codecov_rs/_bindings.abi3.so
...
Dynamic Section:
  RPATH        $ORIGIN/../../codecov_rs.libs
  NEEDED       libgcc_s-1e52349c.so.1
  NEEDED       libc.so
  SONAME       lib_bindings.so
...

v1.7.2 included #2219 which affects how RPATH is set and there's not much else in the release so the regression is probably caused by that? Not clear to me how, though, or why it's apparently musllinux-specific.

Your maturin version (maturin --version)

1.7.2

Your Python version (python -V)

3.12

Your pip version (pip -V)

24.0

What bindings you're using

pyo3

Does cargo build work?

• Yes, it works

If on windows, have you checked that you aren't accidentally using unix path (those with the forward slash /)?

• Yes

Steps to Reproduce

Sorry for the cop-out, but see the bug description.

[messense]

Not clear to me how, though, or why it's apparently musllinux-specific.

Because glibc targets doesn't need to bundle these dylib dependencies.