Open brenthuisman opened 1 year ago
It looks like this is an auditwheel issue, would you agree?
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.
did you learn any more about this?
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.
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/363When 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 bycibuildwheel
, 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