See poudriere output below. =========================================================================== =======================<phase: run-depends >============================ ===== env: USE_PACKAGE_DEPENDS_ONLY=1 USER=root UID=0 GID=0 ===> py311-boost-libs-1.89.0 depends on file: /usr/local/bin/python3.11 - found =========================================================================== =======================<phase: stage >============================ ===== env: NO_DEPENDS=yes USER=nobody UID=65534 GID=65534 ===> Staging for py311-boost-libs-1.89.0 ===> Generating temporary packing list pax: Unable to access libboost_numpy* <No such file or directory> pax: WARNING! These file names were not selected: libboost_numpy* *** Error code 1 Stop. make: stopped making "stage" in /usr/ports/devel/boost-python-libs =>> Cleaning up wrkdir ===> Cleaning for py311-boost-libs-1.89.0 This is in a 16-CURRENT jail.
Created attachment 271292 [details] Full poudriere log. Attached is the full poudriere log.
I'm aslo seeing this with a 14.4-RELEASE-p1 jail in poudriere. Bug 295412 seems to be a duplicate. Anyone found a fix ?
(In reply to Richard Frewin from comment #2) I can reproduce this bug outside of poudriere. The switch to numpy2 precipitated this bug.
*** Bug 295412 has been marked as a duplicate of this bug. ***
I, and the default build cluster, cannot reproduce this. Comparing between what I (and the cluster) have, apart from the boost numpy bits not building at all, the build log is not saying much. However, numpy 2.4 needs a higher baseline of x86 (amd64 and i386 both) CPU features compared to 2.3 and earlier. It is possible that when the boost build process tries to execute numpy for its checks and whatnot, that numpy is (silently to the log) SIGILLing. What does the build machine's dmesg CPU section report?
(In reply to Charlie Li from comment #5) This is exactly what is happening. math/openblas has been built without support for vector extensions. Do we need to add such an option to math/numpy too?
(In reply to Cy Schubert from comment #6) OpenBLAS and AVX are not relevant. AVX is not part of numpy's increased default minimum baseline. Please answer this part, since it can immediately confirm things: > What does the build machine's (for boost-python) dmesg CPU section report?
(In reply to Charlie Li from comment #7) pid 59859 (python3.12), jid 1, uid 0: exited on signal 4 (core dumped) pid 60708 (python3.12), jid 1, uid 0: exited on signal 4 (core dumped) This was in a jail defaulting to python3.12. Same result for python3.11.
I have: CPU: Intel(R) Xeon(R) CPU E5472 @ 3.00GHz (3000.11-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0xce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics That's 15+ years old :-)
My primary build machine: CPU: AMD Phenom(tm) II X4 945 Processor (3014.08-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x100f43 Family=0x10 Model=0x4 Stepping=3 Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x802009<SSE3,MON,CX16,POPCNT> AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!> AMD Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT> SVM: NP,NRIP,NAsids=64 TSC: P-state invariant
Both of these processors were released the same year.
Created attachment 271533 [details] Circumvention This patch circumvents the bug on older hardware.
Both of your chips are v1 with some features from v2 present. Since they are still v1 at the end of the day, they fall short of the v2 default baseline for numpy 2.4. Part of upstream upping the default baseline includes consolidating meson build options so it is currently no longer possible to specify individual features, only microarchitecture groups. I'm seeing about adding a v1 group upstream since their focus was on making v2 the default, also because I'm not sure that the dispatcher can cover all cases that (pre-)compiled would. Bug 295633 (and a mailing list thread) was reported against certain low-end Intel v2 chips lacking the SSE4 suite, which is a slightly different problem than v1 chips not meeting the new default baseline v2.
(In reply to Cy Schubert from comment #10) CPU: Intel(R) Core(TM)2 Duo CPU P9700 @ 2.80GHz (2793.13-MHz K8-class CPU) Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0xc08e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3c11b048c3de3af38dabc809a80dd0fbac51c7ff commit 3c11b048c3de3af38dabc809a80dd0fbac51c7ff Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2026-06-09 02:46:29 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2026-06-09 02:46:29 +0000 math/py-numpy: add SIMD options Per the 2.4 release notes, the default/minimum baseline for compiled optimisations on amd64 and i386 is increased to the v2 microarchitecture. Thus, those using CPUs without the full feature set from v2 will encounter SIGILL when running numpy with the default/minimum baseline. Add option to disable compiled optimisations, relying entirely on dispatched code paths when available and applicable. Not recommended except for very old CPUs. Also add native option. PR: 295633, 295664 math/py-numpy/Makefile | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
The option to disable compiled optimisations has been added to math/py-numpy. It is not and will not be the default, so it will need building from source.
*** Bug 295948 has been marked as a duplicate of this bug. ***