Arch Linux User Repository

@jankoh, thank you for checking openblas and verifying that it is indeed the correct dependency to use.

Package updated.

@MardSeed: Changeing dependencies to blas-openblas introduces error messages from namcap at the moment only:

$ namcap -m $PKG_NAME*.pkg.tar.zst
astromatic-sextractor W: dependency-implicitly-satisfied openblas (libraries-needed ['usr/lib/libopenblas.so.0'] ['usr/bin/sex'])
astromatic-sextractor W: dependency-not-needed blas-openblas

The package blas-openblas itself does not contain needed header file cblas.h; and when using enable-openblas for configure, all we need is package openblas, which includes both the header file as well as the share-object lib. That way the package a) builds in a clean environment, and b) keeps namcap happy.

If those things change in the future, we might reconsider changing the dependencies as suggested.

Please make this depend on blas-openblas. It does not make sense to make it depend on openblas: in Arch, that is a just a barebones package. This application needs also cblas and lapacke interfaces from OpenBLAS, and that is only in blas-openblas package.

The 2.25.0-6 package is only a small update to make the package build again in current arch. Another update to 2.28.0 is on it's way, but needs a little more twaeking to make it build again. It'll take another couple days to make this work.

@MarsSeed, missed the recent update, thanks for notifying. I'll try to provide an update as soon as possible.

Best regards Jan

TLDR; Please change depends openblas-lapack to blas-openblas.

Arch announced on June 14 a new blas-openblas repo package.

That is the same as the earlier AUR package openblas-lapack, providing the OpenBLAS implementation of blas, cblas, lapack, lapacke.

This means the openblas-lapack AUR package should be deleted.

Users and dependent packages should switch to using the blas-openblas repo package instead.

Yes, that seems to be a new feature. I was thinking about it. There are a few considerations:

1) Recently updated sextractor and scamp can use openblas instead but psfex still can't (maybe an update for psfex is on the way as well?). So, for now we should be consistent probably. For example, users who compile sextractor against openblas then need to remove openblas and install atlas-lapack to compile psfex.

2) I can change dependencies from atlas-lapack to ("blas" "lapack" "cblas"). But, this doesn't explicitly state that the user has either atlas-lapack or openblas-lapack installed.

So, my goto for now:

• change the deps to ("fftw" "blas" "lapack" "cblas")

• add a switch to fallback to openblas-lapack if atlas-lapack doesn't exist. However, build will fail if neither of them exists.

• manual "_use_mkl" switch to use mkl instead. This will have priority than others.

Let me know if anyone has further comments or suggestions. Thanks.

Using "--enable-openblas --with-openblas-incdir=/usr/include" arguments in ./configure this package can be built with openblas, instead of atlas.

Also "--enable-mkl" can be used to build the pkg with mkl instead of openblas or atlas.

Using this code the makepkg should be able to detect what library to use:

_OPENBLAS=`pacman -Qq openblas-lapack 2>/dev/null` || true
if [ "$_OPENBLAS" != "" ]; then
    _EXTRAOPTS="--enable-openblas --with-openblas-incdir=/usr/include"
fi

_MKL=`pacman -Qq intel-mkl 2>/dev/null` || true
if [ "$_MKL" != "" ]; then
    _EXTRAOPTS="--enable-mkl"
fi

build() {
  cd $srcdir/${_pkgname}-${pkgver}
  sh autogen.sh
  ./configure --prefix=/usr $_EXTRAOPTS
  make
}