Missing package: depthai

themarpe commented 3 years ago

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:

# depthai-2.3.0.0-cp37-cp37m-linux_armv6l.whl
readelf -A depthai.cpython-37m-arm-linux-gnueabihf.so
# Outputs
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3-D16
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

Compared to other libraries or 3.5:

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

This causes an illegal instruction when trying to load the library.

bennuttall commented 3 years 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:

you change it to build as armv6
we remove the armv6 wheels (this will need to be done manually for any new releases too)
- we build new armv6 wheels and upload these
- we leave armv6 wheels off
we skip this package and let people build from source

themarpe commented 3 years ago

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.

themarpe commented 3 years ago

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?

bennuttall commented 3 years ago

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.

bennuttall commented 3 years ago

@waveform80 looks like we removed the --no-binary flag in this commit: https://github.com/piwheels/piwheels/commit/7a66bab5545cd7e8af0c4583dea27d5b12696d30

themarpe commented 3 years ago

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?

bennuttall commented 3 years ago

Will be able to re-run at will, once the flag is added back in.

bennuttall commented 3 years ago

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

themarpe commented 3 years ago

Thanks - its one of the dependencies. Will try to modify to download an commit archive instead.

themarpe commented 3 years ago

@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?

bennuttall commented 3 years ago

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.

themarpe commented 3 years ago

@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

bennuttall commented 3 years ago

Good news! :+1:

Here you go: http://paste.debian.net/1206923/

themarpe commented 2 years ago

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)?

bennuttall commented 2 years ago

It ran out of memory: https://paste.debian.net/1228216/

themarpe commented 2 years ago

Thanks @bennuttall Great, we have a fix for OOM when building in develop and we'll hopefully release soon:)

bennuttall commented 1 year ago

Build logs are available here: https://www.piwheels.org/project/depthai/

themarpe commented 1 year ago

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?)

piwheels / packages

Missing package: depthai #207