musllinux: builds OK, during testing symbols not found

[brenthuisman]

Description

I'm testing out building musl wheel in our project. The builds pass (after a tiny modification), but our tests don't. They go wrong in the tests where we call a secondary binary packaged with our wheels (modcc): errors like _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE7reserveEm: symbol not found pop up, indicating a linking error.

Part of our workflow is a post repair-wheel command; we use scikit-build, see also https://github.com/pypa/auditwheel/issues/363

When I remove that custom command, perhaps another hint reveals itself: ImportError: Error loading shared library libstdc++-a9383cce.so.6.0.28: No such file or directory (needed by /tmp/tmp.cPnBgl/venv/lib/python3.7/site-packages/arbor/_arbor.cpython-37m-x86_64-linux-gnu.so). Perhaps we're linking erroneously to libstdc++? I'm not sure if this is our fault, since modcc is separate and perhaps not seen by cibuildwheel, but maybe it should?

Build log

https://github.com/brenthuisman/arbor/actions/runs/3686509310/jobs/6238841756#step:7:6565

CI config

https://github.com/arbor-sim/arbor/blob/master/.github/workflows/ciwheel.yml

[joerick]

It looks like this is an auditwheel issue, would you agree?

[brenthuisman]

Possibly, but I'm not convinced yet. This may be due to my unfamiliarity with musl though. The libstdc++ error refers to a library that isn't bundled in the regular builds, not would I expect that. My first thought was that our CMake is not building against musl correctly (or at all). I just don't know which part is supposed to handle this, or is trying to handle it.

The wheel is passing other tests, not involving the external tool, which indicates auditwheel did work.

[joerick]

did you learn any more about this?

[brenthuisman]

Unfortunately not. We merged the changes that make the build pass, but before we upload them, we'll need to check this issue again. If you have any idea of how to diagnose this further, I'd gladly take a look.