Closed themarpe closed 1 year ago
armv6 wheels are just copies of armv7 wheels. This has always been the case and has always worked ok because the OS is armv6 for compatibility. How come yours is choosing armv7?
Options:
I'm actually not sure as well - I've checked some CMake builds on RPi3b of our core and they seem to be ARMv6 as intended. Do you have any build logs or any leads into checking what could be different?
I'll recheck by installing sdist on RPi3b locally first and circle back.
Recheked with sdist on RPi3b (Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux
)
and the final .so is indeed ARMv6.
Do you have any extra information / suggestions of what might be causing an ARMv7 build on your end?
Oh ok I've figured it out - somehow we ended up downloading the armv7 wheel from PyPI (and then copying it to armv6).
This is not supposed to happen. I'm sure we used to use the --no-binary
flag in the pip command but apparently we don't: https://github.com/piwheels/piwheels/blob/master/piwheels/slave/builder.py#L423
Sorry - our fault not yours. I'll sort this out when I get chance.
@waveform80 looks like we removed the --no-binary
flag in this commit: https://github.com/piwheels/piwheels/commit/7a66bab5545cd7e8af0c4583dea27d5b12696d30
Thanks for checking this - I think our project was a bit of an edge case to allow this to split through as we provide the ARMv7 wheels.
Should I create another release which your builder will pick up, or will you be able to rerun (at least the latest version) on your end?
Will be able to re-run at will, once the flag is added back in.
All the builds have been re-run now and all the recent versions are failing: https://www.piwheels.org/project/depthai/
Here's the build output:m http://paste.debian.net/1204714/
It looks like you're trying to perform a git clone during setup, and we don't allow that
Thanks - its one of the dependencies. Will try to modify to download an commit archive instead.
@bennuttall What would be the best way to test this locally or replicate your setup, so I can make sure the problem is resolved before making a pypi release?
I'd suggest: in a clean virtualenv, on a Pi, run python setup.py bdist_wheel
or pip wheel . --no-deps --no-binary :all:
with the environment variable GIT_ALLOW_PROTOCOL=file
set.
@bennuttall thanks for your help - the build went through now successfully. :) Only 3.5 seems to have failed - if possible, can you send me the build log? Otherwise its an older version which isn't that used anymore, so its not so much of an issue
Good news! :+1:
Here you go: http://paste.debian.net/1206923/
Hi @bennuttall
I saw that the latest 2.14.x builds are failing on your builders.
Just wondering what it might be - can you send me the build log of 2.14.1.0
build (either/both Python 3.7 and 3.9)?
It ran out of memory: https://paste.debian.net/1228216/
Thanks @bennuttall
Great, we have a fix for OOM when building in develop
and we'll hopefully release soon:)
Build logs are available here: https://www.piwheels.org/project/depthai/
Thanks @bennuttall - even with further breakdown of bindings for each specific part of the API there still isn't enough memory available. Fortunately we have our own builders to provide wheels for RPi Buster & Bullseye with more memory at disposal.
Not sure how many projects are affected by this, but from our end it'd help if there was either swap or more memory available at these runners (or if you can assign runners with more RAM available to depthai
project?)
Package name: depthai Link to PyPI page: https://www.piwheels.org/project/depthai/ Link to piwheels page: https://pypi.org/project/depthai/ Version: all Python version: 3.7 I am the maintainer: Yes More information:
There seems to be an issue regarding the compiled ARMv6 wheels. I went through ARMv6 wheel versions and the compiled .so library was actually ARMv7 instead of ARMv6, with an exception of older 3.5 wheels:
Compared to other libraries or 3.5:
This causes an illegal instruction when trying to load the library.