Wheels for musl don't work #85
Comments
|
Please also note that this is reported by |
|
This is going to be fun.. I don't have an alpine x86 machine to test on. I only had alpine aarch64 |
|
Works on aarch64: |
|
Note that the symbols are undefined the same way between musl and glibc: musl libc |
|
If I add libpython3 as a dependency, the unfound symbol errors go away: I see we're using Python.h, but it doesn't look like we're linking against libpython. I don't know if this is actually a functional issue. the package does seem to work without the linkage w/ glibc and at least musl aarch64... |
|
@brgl Can you try installing gpiod in a virtualenv? |
|
Apparently, it is recommended to not link against libpython. https://peps.python.org/pep-0513/#libpythonx-y-so-1 So, what we're doing is appropriate. |
I can (on Monday though) but shouldn't it work outside venv anyway? Also: is virtualenv and venv the same thing? Yocto only seems to support virtualenv. |
They should do the same thing, but the command would be |
|
Oof, Yocto. You can also try installing from the sdist and not the wheel, but you'll need the required headers on the machine for that to work. |
|
I know I can install from sdist, that's not an issue. We've had a recipe for yocto for a long time. I'm only using yocto as a minimal system with just python3 and pip to see if the wheels work fine. |
|
Here's with |
|
I tested the wheels in an Alpine container, both 3.14 and 3.20, and they seemed to work fine there, which seems to imply either some python distribution nuance for Yocto or some c level library issue preventing the library from being loaded. I guess I could try to debug this at some point if i could get a yocto image with a toolchain and gdb in it Alpine 3.14: Alpine 3.20: The older version of alpine looks for a lib called "gnu", this is OK because installs were quirked due the ABI not having been broken out correctly in the past. This is not (or shouldn't be) an issue in newer versions of Python. Note in newer versions of some distros (like alpine) you cannot globally install a package via pip as those are intended to be distro provided packages (via apk or apt or yum), which is why i asked to try this in a virtualenv to make sure this wasn't at play in any way. |
|
Ok, I guess this isn't that much of an issue as yocto already has a recipe for python bindings but it would be worth to figure out why this is happening at some point. Let's leave it for now. |
|
Ok, we can leave this open with a plan to investigate further at some point |
|
@brgl, if you pip install # pip3 install --no-binary gpiod gpiod
...
# python3 -c "import gpiod;print(gpiod.__version__)"
2.2.1 |
|
That's essentially how Yocto's recipe works, by manually building/installing the wheel from an sdist AFAIK. My gut says it's a problem with either Python search paths or a libc incompatibility since Yocto builds all of that from scratch. It would be interesting to see just the output from |
Sure but what good is the wheel then? :) |
|
I just noticed you did this in qemu. If you have a yocto config you can share that i can use to reproduce, ill try to give it a shot when i get back from Japan in Nov. |
|
It's literally the simplest Full config is: |
If the |
Ok, so I was being unclear, I meant "sure I can test it" not "sure, it fails too" because I didn't test it. I can do it tomorrow but that would be a whole different environment if I pull in a slew of development tools. And I'm pretty sure it will work then, because just pulling in python3-gpiod from the recipe works fine on musl. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @vfazio
I had some time today to test the wheels and while the ones for glibc work fine for
x86-64andaarch64, the ones linked against musl give me the following error:After having installed them like that:
Could you advise?
The text was updated successfully, but these errors were encountered: