build failure py36-numpy

[dyne2meter]

Another legacy system error...

:info:build clang: numpy/core/src/npymath/halffloat.c
:info:build clang: numpy/core/src/multiarray/mapping.c
:info:build clang: numpy/core/src/common/array_assign.c
:info:build clang: numpy/core/src/common/mem_overlap.c
:info:build clang: numpy/core/src/common/npy_longdouble.c
:info:build clang: numpy/core/src/common/ucsnarrow.c
:info:build clang: numpy/core/src/multiarray/methods.c
:info:build clang: numpy/core/src/common/ufunc_override.c
:info:build clang: numpy/core/src/common/numpyos.c
:info:build clang: numpy/core/src/common/cblasfuncs.c
:info:build clang: numpy/core/src/multiarray/multiarraymodule.c
:info:build clang: numpy/core/src/common/python_xerbla.c
:info:build clang: build/src.macosx-10.11-x86_64-3.6/numpy/core/src/multiarray/nditer_templ.c
:info:build clang: numpy/core/src/multiarray/nditer_api.c
:info:build clang: numpy/core/src/multiarray/nditer_constr.c
:info:build clang: numpy/core/src/multiarray/nditer_pywrap.c
:info:build clang: numpy/core/src/multiarray/number.c
:info:build Running from numpy source directory.
:info:build /opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution option: 'define_macros'
:info:build   warnings.warn(msg)
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-numpy/py36-numpy/work/numpy-1.17.0/numpy/distutils/fcompiler/__init__.py:482: UserWarning: F90FLAGS is used as is, not appended to flags already defined by numpy.distutils! Use NPY_DISTUTILS_APPEND_FLAGS=1 to obtain appending behavior instead (this behavior will become default in a future release).
:info:build   f90flags = self.flag_vars.f90
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-numpy/py36-numpy/work/numpy-1.17.0/numpy/distutils/fcompiler/__init__.py:517: UserWarning: FFLAGS is used as is, not appended to flags already defined by numpy.distutils! Use NPY_DISTUTILS_APPEND_FLAGS=1 to obtain appending behavior instead (this behavior will become default in a future release).
:info:build   fflags = self.flag_vars.flags + dflags + oflags + aflags
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-numpy/py36-numpy/work/numpy-1.17.0/numpy/distutils/fcompiler/__init__.py:530: UserWarning: LDFLAGS is used as is, not appended to flags already defined by numpy.distutils! Use NPY_DISTUTILS_APPEND_FLAGS=1 to obtain appending behavior instead (this behavior will become default in a future release).
:info:build   linker_so_flags = self.flag_vars.linker_so
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-numpy/py36-numpy/work/numpy-1.17.0/numpy/distutils/fcompiler/__init__.py:540: UserWarning: LDFLAGS is used as is, not appended to flags already defined by numpy.distutils! Use NPY_DISTUTILS_APPEND_FLAGS=1 to obtain appending behavior instead (this behavior will become default in a future release).
:info:build   linker_exe_flags = self.flag_vars.linker_exe
:info:build error: Command "/usr/bin/clang -DNDEBUG -g -fwrapv -O3 -Wall -arch x86_64 -DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DHAVE_CBLAS -Ibuild/src.macosx-10.11-x86_64-3.6/numpy/core/src/umath -Ibuild/src.macosx-10.11-x86_64-3.6/numpy/core/src/npymath -Ibuild/src.macosx-10.11-x86_64-3.6/numpy/core/src/common -Inumpy/core/include -Ibuild/src.macosx-10.11-x86_64-3.6/numpy/core/include/numpy -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -I/opt/local/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -Ibuild/src.macosx-10.11-x86_64-3.6/numpy/core/src/common -Ibuild/src.macosx-10.11-x86_64-3.6/numpy/core/src/npymath -Ibuild/src.macosx-10.11-x86_64-3.6/numpy/core/src/common -Ibuild/src.macosx-10.11-x86_64-3.6/numpy/core/src/npymath -c build/src.macosx-10.11-x86_64-3.6/numpy/core/src/umath/loops.c -o build/temp.macosx-10.11-x86_64-3.6/build/src.macosx-10.11-x86_64-3.6/numpy/core/src/umath/loops.o -MMD -MF build/temp.macosx-10.11-x86_64-3.6/build/src.macosx-10.11-x86_64-3.6/numpy/core/src/umath/loops.o.d" failed with exit status 1
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-numpy/py36-numpy/work/numpy-1.17.0" && /opt/local/Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6 setup.py --no-user-cfg build 
:info:build Exit code: 1
:error:build Failed to build py36-numpy: command execution failed
:debug:build Error code: CHILDSTATUS 41816 1
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec build"
:debug:build     (procedure "portbuild::build_main" line 8)
:debug:build     invoked from within
:debug:build "$procedure $targetname"
:error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-numpy/py36-numpy/main.log for details.

[dyne2meter]

main.log

[mf2k (Frank Schima)]

Has duplicate #58772

[gjaeger (Gregor Jäger)]

main.log from ticket 58772

[gjaeger (Gregor Jäger)]

The upgrade from py36-numpy @1.16.3_0+gcc8+openblas to version numpy @1.17.0_0 failed with

sudo port upgrade py36-numpy

or

sudo port upgrade py36-numpy --enforce-variants

based on the unuseful information in #58772 (already closed without solving the problem), I attached my main.log file here.

[kencu (Ken)]

Please don’t be frustrated with our organizational bits.

Having all the info in one ticket improves our ability to fix these errors.

[michaelld (Michael Dickens)]

Thanks for the main.log files. Reviewing them, it looks like NumPy is having SIMD CPU detection issues. Let me see if I can replicate on my OSX computers.

For folks with this issue: what does sysctl -a | grep -i avx return for you?

[michaelld (Michael Dickens)]

For me (2019 MacBook Pro Touch 8-core i9)

% sysctl -a | grep -i avx
hw.optional.avx1_0: 1
hw.optional.avx2_0: 1
hw.optional.avx512f: 0
hw.optional.avx512cd: 0
hw.optional.avx512dq: 0
hw.optional.avx512bw: 0
hw.optional.avx512vl: 0
hw.optional.avx512ifma: 0
hw.optional.avx512vbmi: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: RDWRFSGS TSC_THREAD_OFFSET SGX BMI1 HLE AVX2 SMEP BMI2 ERMS INVPCID RTM FPU_CSDS MPX RDSEED ADX SMAP CLFSOPT IPT SGXLC MDCLEAR IBRS STIBP L1DF ACAPMSR SSBD

[michaelld (Michael Dickens)]

I can replicate one of the logfile on an older CPU running OSX 10.11. The file having issues is numpy/core/src/umath/simd.inc.src ... it's having trouble with _mm512_ intrinsics ... both of which imply to me that the SIMD detection is indeed having some sort of issue(s).

[dyne2meter]

On 10.11.6 iMac core2 duo 20-inch early 2008 (!):

hw.optional.avx1_0: 0
hw.optional.avx2_0: 0

just the two lines

Same on a MacPro, same vintage, running same system, and the log for the failure is also the same, at least at the end.

[gjaeger (Gregor Jäger)]

for me (2017 MacBook Pro, High Sierra 10.13.6):

$ sysctl -a | grep -i avx
hw.optional.avx1_0: 1
hw.optional.avx2_0: 1
hw.optional.avx512f: 0
hw.optional.avx512cd: 0
hw.optional.avx512dq: 0
hw.optional.avx512bw: 0
hw.optional.avx512vl: 0
hw.optional.avx512ifma: 0
hw.optional.avx512vbmi: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: SMEP ERMS RDWRFSGS TSC_THREAD_OFFSET BMI1 AVX2 BMI2 INVPCID SMAP RDSEED ADX IPT SGX FPU_CSDS MPX CLFSOPT MD_CLEAR TSXFA IBRS STIBP L1DF SSBD

[dyne2meter]

I have upgraded py36-numpy on my El Capitan system, using the +clang37 variant (along with +gfortran +openblas). I first tested this on an old Snow Leopard installation where the numpy build was also failing.

[dgarnier (reinrag1a)]

The +clang37 variant worked for me as well on El Capitan and a Mac Pro 1,1. Woot!

[majoc-at-astro (majoc-at-astro)]

Replying to michaelld:

Thanks for the main.log files. Reviewing them, it looks like NumPy is having SIMD CPU detection issues. Let me see if I can replicate on my OSX computers.

For folks with this issue: what does sysctl -a | grep -i avx return for you?

We get curious results: py36-numpy +gcc9 builds under 10.12 and 10.14, but not 10.13. I can't tell whether it's hardware or macOS differences, or possibly GCC, or some combination. System info included as files, but here's the top bits:

10.12 (succeeds):

hw.optional.avx2_0: 0
hw.optional.avx1_0: 0

10.13 (fails):

hw.optional.avx1_0: 0
hw.optional.avx2_0: 0
hw.optional.avx512f: 0
hw.optional.avx512cd: 0
hw.optional.avx512dq: 0
hw.optional.avx512bw: 0
hw.optional.avx512vl: 0
hw.optional.avx512ifma: 0
hw.optional.avx512vbmi: 0

10.14 (succeeds):

hw.optional.avx1_0: 1
hw.optional.avx2_0: 0
hw.optional.avx512f: 0
hw.optional.avx512cd: 0
hw.optional.avx512dq: 0
hw.optional.avx512bw: 0
hw.optional.avx512vl: 0
hw.optional.avx512ifma: 0
hw.optional.avx512vbmi: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C

Let me know, please, if there's other information which may help. Thanks in advance.

[majoc-at-astro (majoc-at-astro)]

Replying to dgarnier:

The +clang37 variant worked for me as well on El Capitan and a Mac Pro 1,1. Woot!

That won't work under 10.14: I get unsupported platform complaints. But it builds fine for us there with +gcc9 instead, presumably because 10.14-compatible hardware sports the appropriate AVX instructions, so that's no problem in practice.

[dyne2meter]

That's pretty much how I thought the chips would fall, forgive the pun. I posted this as a legacy system issue, and I found a solution for it (in the meantime). I agree that a solution which handles the instructions that are currently failing in 10.11 is very desirable. The issues of AVX that are cited here are way, way above my pay-grade.

I stubbornly stick to using a retired OS on my aging (10+ years) hardware not merely to see how long the HW will last and how long the sofware is viable-enough. I've fooled around with MacPorts on enough old hardware and system software to have seen unsupported platform before, but never with a port that I really could not live without, as numpy is.

The SageMath software system does not use the very, very latest gcc version, and will even build an appropriate version if the Xcode tools do not support building every package that it includes. I have built all but the most recent dotted release with the same system that is failing in the present circumstances here. That said, I would not want to keep two different versions of MacPorts gcc around just to avoid this kind of problem.

[dliessi (Davide Liessi)]

$ sysctl -a | grep -i avx
hw.optional.avx1_0: 1
hw.optional.avx2_0: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0

[dliessi (Davide Liessi)]

I get the same errors related to _mm512 with py36-numpy and py37-numpy on OSX 10.11.

[michaelld (Michael Dickens)]

NumPy 1.17.1 is out & I've tested on my 10.14 box & pushed into MacPorts. If folks update the dports & try to build using defaults ... does this new version fix this issue?

​https://github.com/macports/macports-ports/commit/6b6ecc149e503391522015c940f9282abd3f194b

[dyne2meter]

I successfully built the variant py36-numpy +gcc9 +openblas.

When this failure first appeared for me, my default variant was py36-numpy +gfortran +openblas. I had built in the meantime the variant +clang37 +gfortran +openblas, and when I tried to upgrade by taking away the clang37 dependency, I had some sort of build failure, which I can try to reproduce if need be.

Could it be that all along, my problem was the variant I was using? Anyway, all seems well with py36-numpy for me for the time being.

[dliessi (Davide Liessi)]

The errors related to _mm512 persist for me (OSX 10.11).

[majoc-at-astro (majoc-at-astro)]

Replying to michaelld:

NumPy 1.17.1 is out & I've tested on my 10.14 box & pushed into MacPorts. If folks update the dports & try to build using defaults ... does this new version fix this issue?

Not for us, I'm afraid: I see the same AVX-512 errors with macOS 10.13 on an old-style Mac Pro (cheesegrater classic?), using +gcc9 +openblas. I'll retry with +gfortran +openblas, but it'll be a wee while.

[GiovanniBussi (Giovanni)]

Replying to majoc-at-astro:

Replying to michaelld:

NumPy 1.17.1 is out & I've tested on my 10.14 box & pushed into MacPorts. If folks update the dports & try to build using defaults ... does this new version fix this issue?

Not for us, I'm afraid: I see the same AVX-512 errors with macOS 10.13 on an old-style Mac Pro (cheesegrater classic?), using +gcc9 +openblas. I'll retry with +gfortran +openblas, but it'll be a wee while.

I managed to install py37-numpy +clang37 on my system:

macOS 10.11.6 15G22010

Xcode 8.1 8B62

Notice that also the buildbot with 10.11 is not able to compile it (​http://packages.macports.org/py37-numpy/)

[majoc-at-astro (majoc-at-astro)]

Replying to majoc-at-astro:

Replying to michaelld:

NumPy 1.17.1 is out & I've tested on my 10.14 box & pushed into MacPorts. If folks update the dports & try to build using defaults ... does this new version fix this issue?

Not for us, I'm afraid: I see the same AVX-512 errors with macOS 10.13 on an old-style Mac Pro (cheesegrater classic?), using +gcc9 +openblas. I'll retry with +gfortran +openblas, but it'll be a wee while.

@1.17.1 builds fine on our test builders (and apparently for the buildbots) with +gfortran +openblas for the macOS versions we're interested in:

10.13.6 (17G8030); Xcode 10.1 (10B61)
10.14.6 (18G95);   Xcode 10.3 (10G8)

Final full-build testing, inc using defaults for SciPy and arpack, in progress. Hope this helps, folks.

[GiovanniBussi (Giovanni)]

@michaelld would it be possible to modify the Portfile so that when using MacOS 10.11 the +clang37 variant is automatically selected?

This would fix the installation on MacOS 10.11.

Ideally, one should also rebuild, on the 10.11 buildbots, all the ports depending (directly or indirectly) on numpy on MacOS 10.11 that were updated in the meanwhile. Indeed, all the binaries for 10.11 are now missing. See e.g.:

​http://packages.macports.org/py37-numpy/

​http://packages.macports.org/py37-scipy/

​http://packages.macports.org/py37-pandas/

​http://packages.macports.org/py37-numba/

​http://packages.macports.org/py37-biopython/

[dyne2meter]

@giovanni

I am able to build py36-numpy on a 10.11 system with the variant +gcc9 +openblas. Perhaps you should check your installation of the few ports that numpy depends on for building or running. In particular, you should check your variant on fftw-3. Of course, you may find you can upgrade it without doing any of that. I have discovered that +clang37 is not necessary in an absolute sense, and I think that is a good thing.

[GiovanniBussi (Giovanni)]

Replying to dyne2meter:

I tried on my system ant variant +gcc9 works as well. I don't know which should be preferred among +clang37 and +gcc9. In any case, I would suggest having one of them as the default at least on 10.11 and to trigger the buildbot to rebuild the relevant ports.

Thanks!

Giovanni

PS I might have sent this message twice by mistake

@giovanni

I am able to upgrade py36-numpy on a 10.11 system with the variant +gcc9 +openblas. Perhaps you should check your installation of the few ports that numpy depends on for building or running. In particular, you should check your variant on fftw-3. Of course, you may find you can upgrade it without doing any of that. I have discovered that +clang37 is not necessary in an absolute sense, and I think that is a good thing, not least because it is only required for building that variant.

[michaelld (Michael Dickens)]

I just pushed NumPy 1.17.2 < ​https://github.com/macports/macports-ports/commit/c54c0667e73a5e30932e2a5e750374e2f54839e3 >. Maybe it helps with the issue here?

[dyne2meter]

This update has created a minor issue for me. As noted above, I had installed variant py36-numpy +gcc9 +openblas. When I attempted port upgrade outdated, an error announced a conflict with variant +clang37. I forced the update with port install py36-numpy -clang37 +gcc9 +openblas. Hopefully, the next update will work with port upgrade outdated.

[michaelld (Michael Dickens)]

I finally had some time and an OSX 10.11 install to do testing on ... just pushed ​https://github.com/macports/macports-ports/commit/8496337d4cbd6633447dea29a4c3626f633364e6 , which blocks older Apple Clang compilers because they claim SIMD support but don't carry through & error out during builds. I've seen this on a variety of ports of recent, and have fixed those I can easily do so on. I'm guessing with this fix I can remove the +clang37 variant entirely; I'm trying to install clang-3.7 to verify that it works (at all), and then disabling it with the new block to verify that side.

[michaelld (Michael Dickens)]

WIth the change noted just prior, I no longer need +clang37 ... the build works without it just fine. I also can't get clang-3.7 to build, so this is good since otherwise I'm not sure what I'd do to get NumPy on OSX 10.11! I'm going to go ahead and disable as a default variant ... not remove it yet, but that will be the next step if it's truly not required any longer.

@kencu : do you have any idea why we have the +clang37 variant? I'm guessing it's for older OSX ... which is why I'm tagging you here ... I'll look through the GIT log too, but maybe you know?

[michaelld (Michael Dickens)]

Here's the commit that added it: ​https://github.com/macports/macports-ports/commit/55351ea6f73909cae47d35db3b97c8804abb14b0

[michaelld (Michael Dickens)]

I can't find a PR for this change ... hmm ... maybe Chris just pushed it directly? Could be ...

[dyne2meter]

I found that I needed clang37 for 10.6 numpy.

I have a laptop that won't run anything higher. I'm not going on the road much, lately. Not at all, actually.

[chrstphrchvz (Christopher Chavez)]

py36-numpy has since been updated to 1.91.1 and ​is known to build successfully on 10.11. Is this ticket still relevant or can it be closed?

[dyne2meter]

I have py38-numpy @1.19.1_0; afaiac, this can be closed.