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

Unsupported Wheel on x86_64 Intel Chip Mac running OSX 13.4 #160

Open
danielfrees opened this issue Jun 2, 2023 · 4 comments
Open

Unsupported Wheel on x86_64 Intel Chip Mac running OSX 13.4 #160

danielfrees opened this issue Jun 2, 2023 · 4 comments

Comments

@danielfrees
Copy link

danielfrees commented Jun 2, 2023

I have a working CMakeLists.txt file which generates both an executable (racplusplus_exe) and a static library (racplusplus.cpython-311-darwin.so) wrapped with pybind. The executable runs perfectly, and I can import the static library in python and run functions successfully.

When I use setup.py to python3 setup.py bdist_wheel I get a wheel built in dist/racplusplus-0.9-cp311-cp311-macosx_13_0_x86_64.whl. But whenever I try to pip install the wheel I get the error "ERROR: racplusplus-0.9-cp311-cp311-macosx_13_0_x86_64.whl is not a supported wheel on this platform."

During the build output I see multiple lines with mention macosx 10.9 for some reason. ie: "installing to build/bdist.macosx-10.9-x86_64/wheel". So I wonder if somehow the wheel is being built for the wrong macOSX, even though the final wheel name has the correct OS?

I have tried manually setting

python os.environ["ARCHFLAGS"] = "-arch x86_64 -mmacosx-version-min=13.0"

and also manually setting

python os.environ['MACOSX_DEPLOYMENT_TARGET'] = '13.0'

in "setup.py", but neither of these environment variables seems to be respected.

Any ideas what's going on? Not sure this is inherently an issue with setup.py for newer OS's or if I'm not understanding how to specify the wheel architecture correctly.

@henryiii
Copy link
Collaborator

henryiii commented Jun 2, 2023

This example is not helpful if you have a CMakeLists.txt. You should look at https://github.com/pybind/scikit_build_example, which is much better, or https://github.com/pybind/python_example, which is probably what you based your setup.py on. That has been updated a couple of years ago with the correct way to handle ARM and macOS, but I'd guess you got a copy (or a copy of a copy...) of that one. But continually checking the example setup.py and manually updating yours is not good software engineering; it's better to use something like scikit-build-core and take advantage of the builder updating for new architectures and things for you.

@henryiii
Copy link
Collaborator

henryiii commented Jun 2, 2023

Oh, I did think you were using M1 for some reason... Going to guess you have separate CMake and setuptools builds; it's better to use scikit-build-core, but I still have a package (boost-histogram) that does this, so I can't speak too harshly about it. :)

You should probably start with pip debug --verbose, and make sure cp311-cp311-macosx_13_0_x86_64 is in that list; I'd guess it is though. Looks like you are getting a tag in the wheel that's not matching the tag in the filename, pip reads the wheel tag. You can look in the .dist-info directory and check, wheels are just .zip files.

Do you have a source code link? It's hard to debug without seeing any code.

Also, never run setup.py <stuff>. You should use pip install -v . or pipx run build instead of setup.py commands.

@danielfrees
Copy link
Author

Hi Henry, thanks so much for the quick reply and feedback. I wasn't aware of scikit-build-core (is that an extensible framework for pyproject.toml deployement?) I am in general completely brand new to C++ software development/ compilation (I did learn and use C++ extensively in college but it was all contained within XCode). I have deployed several python packages but that's always much simpler.

I'll make sure to run that debug command and investigate .dist-info again (I actually did check dist-info a little while ago and it looked fine as far as I could tell, but I may need to give it a closer look). If I find issues, is there an easy way to trace where the metadata in .dist-info comes from in terms of my setup pipeline?

Here is my source code: https://github.com/mediboard/racplusplus.

Good to know on that last point, I was running setup.py directly because I saw it in a youtube video, but again I'm brand new so I really appreciate the feedback.

@danielfrees
Copy link
Author

Also I got my setup.py from https://github.com/pybind/cmake_example/blob/master/setup.py and I have no idea how I accidentally created my Issue here, but it seems it may have been a happy fluke since you've already given me some great ideas on what to look into.

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