Closed barracuda156 closed 6 months ago
dnicolodi
commented
6 months ago This error comes from a code path present only in the version of Meson vendored in NumPy.
From the look of it, you are trying to build NumPy on a macOS version that is so old that the platform detection code used by NumPy does not even run, let alone return a valid output. What does xcrun -sdk macosx --show-sdk-version return on your system?
barracuda156
commented
6 months ago @dnicolodi This is invalid syntax for xcrun on < 10.7 (corrected: <= 10.7):
svacchanda$ xcrun -sdk macosx --show-sdk-version
xcrun: error: unrecognized option: --show-sdk-version
usage:
xcrun [-verbose] [-no-cache] [-kill-cache] [-sdk <sdkroot>] [-log] [-run] <utility> [utility argument(s) ...]
xcrun [-verbose] [-no-cache] [-kill-cache] [-sdk <sdkroot>] -find <utility>
<tool> [tool arguments ...]Generally speaking, it should be avoided in any case, since there may be more than one SDK present and not necessarily one will build against a matching SDK (matching one is a norm, but not requirement).
dnicolodi
commented
6 months ago This is a NumPy issue. Please report it to the NumPy project. There isn't anything meson-python can do about it.
barracuda156
commented
6 months ago @dnicolodi Got it, thank you. I brought is here only because the log explicitly stated This is a Meson bug and should be reported!.
The error does not appear related to xcrun or SDK though, what fails is this:
blas = dependency(_name, modules: ['cblas'] + blas_interface, required: false)Relevant code chunk is:
# First try scipy-openblas, and if found don't look for cblas or lapack, we
# know what's inside the scipy-openblas wheels already.
if blas_name == 'openblas' or blas_name == 'auto'
blas = dependency('scipy-openblas', required: false)
if blas.found()
blas_name = 'scipy-openblas'
endif
endif
if blas_name == 'auto'
foreach _name : get_option('blas-order')
if _name == 'mkl'
blas = dependency('mkl',
modules: ['cblas'] + blas_interface + mkl_opts,
required: false, # may be required, but we need to emit a custom error message
version: mkl_version_req,
)
# Insert a second try with MKL, because we may be rejecting older versions
# or missing it because no pkg-config installed. If so, we need to retry
# with MKL SDL, and drop the version constraint (this always worked).
if not blas.found() and mkl_may_use_sdl
blas = dependency('mkl', modules: ['cblas', 'sdl: true'], required: false)
endif
else
if _name == 'flexiblas' and use_ilp64
_name = 'flexiblas64'
endif
blas = dependency(_name, modules: ['cblas'] + blas_interface, required: false)
endif
if blas.found()
break
endif
endforeach
else
if blas_name == 'mkl'
blas = dependency('mkl',
modules: ['cblas'] + blas_interface + mkl_opts,
required: false,
version: mkl_version_req,
)
# Same deal as above - try again for MKL
if not blas.found() and mkl_may_use_sdl
blas = dependency('mkl', modules: ['cblas', 'sdl: true'], required: false)
endif
else
blas = dependency(blas_name, modules: ['cblas'] + blas_interface, required: false)
endif
endifAnd it only fails when pep517 (meson-python) is used, not otherwise. (So no, it is not a problem of old macOS as such.)
rgommers
commented
6 months ago I brought is here only because the log explicitly stated
This is a Meson bug and should be reported!.
That is because it's a feature that is about to be upstreamed into Meson, but already present in NumPy's vendored copy of Meson. Right now it's indeed a NumPy bug. If you wouldn't mind opening a new issue on the NumPy issue tracker, I'll look into fixing it.
dnicolodi
commented
6 months ago The error does not appear related to
xcrunor SDK though
The raised exception is subprocess.CalledProcessError: Command '['xcrun', '-sdk', 'macosx', '--show-sdk-version']' returned non-zero exit status 64. so I don't see how this is not related to xcrun.
barracuda156
commented
6 months ago xcrun spits an error due to wrong syntax, but it does not break the build, at least from what it looks:
1) de facto, the build continues to run until BLAS variants evaluation, consistently; 2) the error log points to a chunk of code related to BLAS variants, apparently to this one: https://github.com/numpy/numpy/blob/08e6252fc38d3b463879afce733c889df2af1d34/numpy/meson.build#L111
BTW, xcrun fails identically with R, and nothing gets broken with it, every package installs, ignoring the silly error.
barracuda156
commented
6 months ago UPD. I will investigate today if it in fact xcrun causing the breakage and the log misattributes it to BLAS search.
barracuda156
commented
6 months ago @dnicolodi You were right on this issue, it is xcrun: the log mislead me, pointing meson.build. What fails is the following from mesonbuild/dependencies/blas_lapack.py:
def check_macOS_recent_enough(self) -> bool:
# We need the SDK to be >=13.3 (meaning at least XCode 14.3)
cmd = ['xcrun', '-sdk', 'macosx', '--show-sdk-version']
sdk_version = subprocess.run(cmd, capture_output=True, check=True, text=True).stdout.strip()
macos_version = platform.mac_ver()[0]
deploy_target = os.environ.get('MACOSX_DEPLOYMENT_TARGET', macos_version)
return sdk_version >= '13.3' and deploy_target >= '13.3'I do not know why this restriction, it is totally unjustified. And yeah, this xcrun syntax has to be fixed or the whole chunk rewritten in a better way.
Thank you for pointing this out, I will add a note to the issue in numpy upstream.
I am not sure if this is a
mesonbug as the output states, but it only happens whenpep715is used, everything else being identical.P. S. Ignore “unsupported architecture” claim: arch detection has been broken in
numpyforever, but it is not the cause of the error.