[Bug 273219] math/openblas: update to 0.3.24

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 17 Sep 2023 14:09:44 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273219

--- Comment #5 from Daniel Engberg <diizzy@FreeBSD.org> ---
They're packaging related, nothing specific to Linux.

Portlint won't complain about existing upstream release archives because it has
never been able to so. Porters Handbook recommends usage of release archives to
avoid breakage and as of GitHub's service policy changes please switch as it
will avoid breakage. See
https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github
for more information.

Both AVX and AVX2 are SMID instructions? Port (OpenBLAS) also appears to
violate C(XX)FLAGS policy.
https://docs.freebsd.org/en/books/porters-handbook/book/#dads-cflags

Looking at my local box, "cc -DCBLAS -c -O2 -pipe -march=tigerlake 
-fstack-protector-strong -fno-strict-aliasing  -O2 -DSMALL_MATRIX_OPT
-DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT
-fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=64
-DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1
-DBUILD_COMPLEX16=1 -DVERSION=\"0.3.20\" -msse3 -mssse3 -msse4.1 -mavx -mavx2
-march=skylake-avx512 -mavx2 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME
-UCHAR_CNAME -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\"
-DCHAR_CNAME=\"\" -DNO_AFFINITY -I. -O2 -DSMALL_MATRIX_OPT
-DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT
-fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=64
-DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1
-DBUILD_COMPLEX16=1 -DVERSION=\"0.3.20\" -msse3 -mssse3 -msse4.1 -mavx -mavx2
-march=skylake-avx512 -mavx2 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME
-UCHAR_CNAME -DASMNAME=cblas_strmv -DASMFNAME=cblas_strmv_ -DNAME=cblas_strmv_
-DCNAME=cblas_strmv -DCHAR_NAME=\"cblas_strmv_\" -DCHAR_CNAME=\"cblas_strmv\"
-DNO_AFFINITY -I.. -I. -UDOUBLE  -UCOMPLEX trmv.c -o cblas_strmv.o"

Ideally we should rely on CPUTYPE for any type of CPU specific optimization in
the tree whenever possible.

Shared library support has always been prefered,
https://docs.freebsd.org/en/books/porters-handbook/book/#bundled-libs-practices
but I dont think you need a separate package for it unless it clashes with
other ones in tree.

Best regards,
Daniel

-- 
You are receiving this mail because:
You are the assignee for the bug.