Deploy targets ( musl, manylinux, audiwheels )

[RaulTrombin]

Hey, I'm deploying a solution for embeeded linux devices, it's a library that is building thourgh a rust core and binding it to C and Python.

I'm having sucess to build it for armv7 and aarch64, both for manylinux and musl targets.

CI Link - deploys, workflow and status

My question is, they generating .so files inside the python wheels.

➜  python tree navigator-0.1.0-cp39-abi3-manylinux_2_17_armv7l.manylinux2014_armv7l
navigator-0.1.0-cp39-abi3-manylinux_2_17_armv7l.manylinux2014_armv7l
├── navigator
│   ├── __init__.py
│   └── navigator.abi3.so
└── navigator-0.1.0.dist-info
    ├── METADATA
    ├── RECORD
    └── WHEEL

3 directories, 5 files
➜  python tree navigator-0.1.0-cp39-abi3-musllinux_1_1_armv7l 
navigator-0.1.0-cp39-abi3-musllinux_1_1_armv7l
├── navigator
│   ├── __init__.py
│   └── navigator.abi3.so
├── navigator-0.1.0.dist-info
│   ├── METADATA
│   ├── RECORD
│   └── WHEEL
└── navigator.libs
    └── libgcc_s-5b5488a6.so.1

They are generated the files inside as dynamic linked libraries, "*so".
I'm tryng to apply static link into this, but no sucess.

How to static link the musl libs inside the python wheel?
If I do this, the manylinux(gcc) target isn't necessary anymore?

Basically my raspbian says it's not compatible with the musl generated wheel, but if I put the musl libc inside it should works, is it right?

[konstin]

Basically my raspbian says it's not compatible with the musl generated wheel, but if I put the musl libc inside it should works, is it right?

No, you need to use the same libc that python uses. If you are on raspbian, your python will most likely use glibc, so you need to use manylinux builds and can't use musllinux builds.

Since you're writing a module that cpython will load and interact with, you can't use static linking but must use dynamic linking.