Repository navigation
BLD: win32 not using python architecture #24704
Description
Activity
You may also need to set PIP_EXTRA_INDEX_URL.
The actual issue here is that MSVC for x86-64 is being used to try and build 32-bit Python extension modules:
C compiler for the host machine: cl (msvc 19.35.32217.1 "Microsoft (R) C/C++ Optimizing Compiler Version 19.35.32217.1 for x64")To get past that problem, the 32-bit MSVC compiler must be activated so that it gets used for the whole build. The
msdevshellGitHub Action is a convenient way of doing that, and is what we use in our own wheel build config:.numpy/.github/workflows/wheels.yml
Lines 102 to 106 in e536952
This problem is specific to Windows + 32-bit Python, so I don't expect to see more of these issues once we upload
win32wheels.I'll note that
distutilsdidn't have this problem, because it could only worry about Python extension modules and hence default to the 32-bit compiler on a 64-bit OS when the user did not explicitly ask for that. Meson has many more languages to support, so compiler selection isn't going to be special-cased for the specific Python interpreter build you happen to be using.Reacted by Nathan GoldbaumLet's close this issue as soon as we have
win32wheels on PyPI for Python 3.12This has been resolved. Thanks!
The actual issue here is that MSVC for x86-64 is being used to try and build 32-bit Python extension modules:
I just hit this trying to set up a 32 bit windows numpy development environment to run down an issue happening on CI.
I eventually found this thread via a google search but would have gotten here faster with a nicer error message.
@rgommers Is there a way for meson to detect that x64 MSVC is activated on x86 python and fail early?
also for anyone else trying to do this, I was able to build numpy with a 32 bit python in a VS command prompt after running
vcvars32.bat.Reacted by Kevin EavesThe error message is pretty clear about the problem:
Need python for x86_64, but found x86. The trouble is, it doesn't really tell you what you want to know here, which is how to avoid the problem. One way would be to amend the error message in Meson, if it can be made specific to Windows.Since
dependency('python')fails, there's not much we can do to introspect the found installation. One thing we could do is to check a symbol fromPython.hfirst, e.g. there's this we could fish out:/* The size of `uintptr_t', as computed by sizeof. */ #define SIZEOF_UINTPTR_T 8Perhaps
cc.sizeof('size_t') != SIZEOF_UINTPTR_Twould work. The trouble is, to make sure we pick up the correctPython.h, we already need thepy_depobject. Existing checks look like:cc.sizeof('Py_intptr_t', dependencies: py_dep, prefix: '#include <Python.h>'))
So, doesn't look like there's anything we can check. I'll have a look at adding a sentence to the error message.
xref mesonbuild/meson#11435 for the most relevant upstream issue.
From: pyproj4/pyproj#1330 (comment)
Possible to build based on python architecture and not host machine architecture? Other suggestions?