Fails to build with ILP64 on Alpine Linux x86_64 since arpack 3.9.0

[jirutka]

Expected behavior

Should build fine.

Actual behavior

Fails to build.

Where/how to reproduce the problem

• arpack-ng: 3.9.1
• OS: Alpine Linux Edge x86_64
• compiler: gcc (Alpine 13.2.1_git20240309)
• environment: FFLAGS=-fallow-argument-mismatch
• configure: ./configure --prefix=/usr --enable-static --enable-icb --with-blas=openblas64_ --with-lapack=openblas64_ LIBSUFFIX=64_ SYMBOLSUFFIX=_64 INTERFACE64=1

Steps to reproduce the problem

On Alpine Linux Edge x86_64:

apk add build-base openblas-dev autoconf automake gfortran libtool
./bootstrap
./configure \
	--prefix=/usr \
	--enable-shared \
	--enable-static \
	--enable-icb \
	--with-blas=openblas64_ \
	--with-lapack=openblas64_ \
	LIBSUFFIX=64_ \
	SYMBOLSUFFIX=_64 \
	INTERFACE64=1
make

Error message

snaup2.f:462:72:

  462 |          call scopy(kplusp, bounds, 1, workl(kplusp**2+2*kplusp+1), 1)
      |                                                                        1
Error: Syntax error in argument list at (1)

See arpack-3.9.1-build.log for full log.

Traces

N/A

Callstack

N/A

Notes, remarks

Non-ILP64 builds fine. ILP64 builds fine for arpack-ng 3.8.0.

[fghoussen]

Error: Syntax error in argument list at (1)

Is your BLAS / LAPACK compiled with ILP64 support?

arpack-ng/.github/workflows/jobs.yml

Line 156 in 51ce061

./configure --enable-icb --with-blas=mkl_gf_ilp64 --with-lapack=mkl_gf_ilp64

[jirutka]

Yes, --with-blas=openblas64_ --with-lapack=openblas64_ is from openblas-ilp64 which is OpenBLAS ILP64 variant (see here).

[fghoussen]

Never tested with OpenBLAS ILP64, but only with MKL ILP64.
Does OpenBLAS test suite runs OK with ILP64? If yes, does one of these tests use scopy?

[fghoussen]

May be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967951

[fghoussen]

ILP64 builds fine for arpack-ng 3.8.0.

With which version of OpenBLAS? Does it still work with this old specific version of OpenBLAS?
I had a quick look: I do not see any change that could break ILP64 at arpack-ng side.

[jirutka]

As I said, arpack-ng 3.8.0 builds fine with the same flags for ILP64 and the same OpenBLAS version (0.3.26), 3.9.0 fails to build.

[fghoussen]

As you use --with-blas=openblas64_, I guess (?) the openblas build/install you use would have produced 64_ suffixed openblas symbols and binaries (.a or .so file)? If so, you may try to (or should?) use SYMBOLSUFFIX=64_ (underscore last) instead of SYMBOLSUFFIX=_64 (underscore first)? Or maybe simply SYMBOLSUFFIX=_? Or any other suffix according to the convention the openblas lib did use to export symbols in this specific ILP64 case?

How are openblas libraries named, and, how does they export symbols? (I have no idea - I do not use openblas)
In openblas, do you link with the expected ILP64 suffixed lib (static-archive or shared-object) referencing (using SYMBOLSUFFIX) the expected ILP64 symbols inside these libs? You may check that with nm: the ILP64 openblas lib must export the same symbols as the ones arpack-ng expect based on SYMBOLSUFFIX (check FFLAGS reported by arpack-ng configure log - summary at the end).

If arpack-ng reports:

--------------------------------------------------
Configuration summary for ARPACK-NG 3.9.1
--------------------------------------------------
Installation prefix : /usr
MPI enabled         : no (ICB provided )
ICB enabled         : yes
INTERFACE64         : 1
F77                 : x86_64-alpine-linux-musl-gfortran
FFLAGS              :  -fallow-argument-mismatch -fdefault-integer-8  -cpp -Dsaxpy=saxpy_64

Then the openblas lib must report (for saxpy and all other symbols like scopy):

>> nm /path/to/libopenblas64_.so | grep saxpy_64
0000000000000000 T saxpy_64

Is this the case at your side?

arpack-ng/configure.ac

Lines 288 to 310 in 51ce061

	dnl As BLAS/LAPACK does not provide ICB, we may have to deal with symbols the old-fashion-boring-cumbersome-fortran/C way...
	if test x"$SYMBOLSUFFIX" != x""; then
	dnl Need to rely on non-F77 features
	AC_FC_LINE_LENGTH(unlimited)
	FFLAGS="$FFLAGS $ac_cv_fc_line_length"
	AC_LANG_PUSH([Fortran 77])
	AX_CHECK_COMPILE_FLAG(-cpp, FFLAGS="$FFLAGS -cpp",
	AX_CHECK_COMPILE_FLAG(-fpp, FFLAGS="$FFLAGS -fpp",
	AC_MSG_WARN([configure does not know how to enable your Fortran compiler's preprocessor: set it manually via FFLAGS.])))
	AC_LANG_POP([Fortran 77])
	BLASFUNS1="axpy copy gemv geqr2 lacpy lae2 lahqr lanhs larnv lartg lascl laset lasrt scal trevc trmm trsen gbmv gbtrf gbtrs gttrf gttrs pttrf pttrs"
	BLASFUNS2="dot ger labad laev2 lamch lanst lanv2 lapy2 larf larfg lasr nrm2 orm2r rot steqr swap"
	BLASFUNS3="dotc geru unm2r"
	BLASFUNS4="COPY LABAD LAMCH LANHS LANV2 LARFG ROT GEMV"
	BLASFUNS5="scnrm2 dznrm2 csscal zdscal"
	FUNS1="$BLASFUNS1 $BLASFUNS2"
	for f in $FUNS1
	do
	FFLAGS="$FFLAGS -Ds$f=s$f$SYMBOLSUFFIX -Dd$f=d$f$SYMBOLSUFFIX"

AFAIK, the common BLAS/LAPACK libraries (netlib, openblas, ...) do not provide ISO_C bindings (huge work) that would enable the compiler to handle/detect types correctly (int or int64_t)... There is no way to automate/detect correct symbols to use: the only way is to rely on ugly SYMBOLSUFFIX trick which means basically linking-by-hand: for this, you need to know for sure which symbol is exported how-and-why by which lib (in case you have different flavors of the same .so installed in the same install directory as it happens sometimes).

arpack-ng 3.8.0 builds fine

Did the test suite run OK?
Sometimes these kind of errors may be silent at build time but will trigger failures (core dumps) at run time.

[fghoussen]

I guess (?) the openblas build/install you use would have produced 64_ suffixed

Another test you may try is to install an ILP64 version of openblas without any suffixing: this way there would be only one lib exporting always the same good-old expected-and-regular symbols (scopy symbol == ILP64 symbol) so you can drop SYMBOLSUFFIX at arpack-ng side.