Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wheels #17

Open
0x0L opened this issue Feb 26, 2023 · 7 comments
Open

Wheels #17

0x0L opened this issue Feb 26, 2023 · 7 comments

Comments

@0x0L
Copy link
Owner

0x0L commented Feb 26, 2023

I believe the CI built wheels are still wrong, we should have the same dependencies as pyarrow

  • on macos: 10.14 (for x86_64)
  • on linux: manylinux_2_17

ATM we have
macos 10.9 / manylinux_2_5

@0x0L
Copy link
Owner Author

0x0L commented Feb 27, 2023

I guess for macos we need to set MACOSX_DEPLOYMENT_TARGET="10.14" in the env

@rdbisme
Copy link
Collaborator

rdbisme commented Feb 27, 2023

I think what's happening here is that, since we ignore pyarrow, the repair tools can't know the dependency. The right way to do it would be a way to "scan dependencies" but choose what to copy.

The delocate tool for macOS seems to support this.

@0x0L
Copy link
Owner Author

0x0L commented Feb 27, 2023

The wheel is built with the wrong platform tag, repairing does not change that
I don't understand why there isn't a min_macos kwargs in setuptools.

@rdbisme
Copy link
Collaborator

rdbisme commented Feb 27, 2023

For what I understand, auditwheel relabels the wheel based on the minimum manylinux policy supported by the dependencies.

In our case, if there was a way of keeping libarrow in the dependencies, but avoid copying the library, it would create a manylinux_2_17 wheel.

I don't know how the macos minimum version work, but I guess it should work the same? If you build something compatible with macos 10.9+, that depends on something compatible macos 10.14+, if the ABI is backwards compatible, you should not need to recompile and the wheel should be relabeled for 10.14.

@0x0L
Copy link
Owner Author

0x0L commented Feb 27, 2023

On my local build, if I just do pip install . -vv --no-build-isolation I get warnings: [Actually it's also in the build logs of the CI]

ld: warning: dylib (/Users/xav/.micromamba/envs/pgeon-dev/lib/python3.11/site-packages/pyarrow/libarrow_python.dylib) was built for newer macOS version (10.14) than being linked (10.9)
  ld: warning: object file (build/temp.macosx-10.9-x86_64-cpython-311/libpgeon_cpp.a(api.o)) was built for newer macOS version (10.14) than being linked (10.9)
  ld: warning: object file (build/temp.macosx-10.9-x86_64-cpython-311/libpgeon_cpp.a(table_builder.o)) was built for newer macOS version (10.14) than being linked (10.9)
  ld: warning: object file (build/temp.macosx-10.9-x86_64-cpython-311/libpgeon_cpp.a(pg_interface.o)) was built for newer macOS version (10.14) than being linked (10.9)
  ld: warning: object file (build/temp.macosx-10.9-x86_64-cpython-311/libpgeon_cpp.a(builder.o)) was built for newer macOS version (10.14) than being linked (10.9)
  ld: warning: object file (build/
...

The wheel produced is tagged 10.9
Created wheel for pgeon: filename=pgeon-0.0.0-cp311-cp311-macosx_10_9_x86_64.whl size=98067

Setting MACOSX_DEPLOYMENT_TARGET removes the linker warnings and produce the expected wheel ilename=pgeon-0.0.0-cp311-cp311-macosx_10_14_x86_64.whl

@0x0L
Copy link
Owner Author

0x0L commented Feb 27, 2023

@0x0L
Copy link
Owner Author

0x0L commented Feb 27, 2023

#24 sets MACOSX_DEPLOYMENT_TARGET="10.14"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants