Arguments of dsyevx, dgeevx changed and now the treekin package is broken

[yurivict]

Recently there were some changes to these functions and now the biology/treekin port breaks:

In file included from calcpp.cpp:6:
./calcpp.h:317:74: error: too few arguments to function call, expected 23, have 20
              (double *)z, ldz, (double *)work, lwork, iwork, ifail, info);
                                                                         ^
/usr/local/include/lapacke/lapack.h:17248:6: note: 'dsyevx_' declared here
void LAPACK_dsyevx_base(
     ^
/usr/local/include/lapacke/lapack.h:17247:28: note: expanded from macro 'LAPACK_dsyevx_base'
#define LAPACK_dsyevx_base LAPACK_GLOBAL(dsyevx,DSYEVX)
                           ^
/usr/local/include/lapacke/lapacke_mangling.h:5:34: note: expanded from macro 'LAPACK_GLOBAL'
#define LAPACK_GLOBAL(name,NAME) name##_
                                 ^
<scratch space>:326:1: note: expanded from here
dsyevx_
^
In file included from calcpp.cpp:6:
./calcpp.h:373:33: error: too few arguments to function call, expected 27, have 23
              lwork, iwork, info);
                                ^
/usr/local/include/lapacke/lapack.h:1900:6: note: 'dgeevx_' declared here
void LAPACK_dgeevx_base(
     ^
/usr/local/include/lapacke/lapack.h:1899:28: note: expanded from macro 'LAPACK_dgeevx_base'
#define LAPACK_dgeevx_base LAPACK_GLOBAL(dgeevx,DGEEVX)
                           ^
/usr/local/include/lapacke/lapacke_mangling.h:5:34: note: expanded from macro 'LAPACK_GLOBAL'
#define LAPACK_GLOBAL(name,NAME) name##_
                                 ^
<scratch space>:377:1: note: expanded from here
dgeevx_
^

https://www.tbi.univie.ac.at/RNA/Treekin/

I am the maintainer of the FreeBSD port but I have no idea how to fix it now.

Were these functions changed intentionally or accidentally?

lapack-3.10.0

[martin-frbg]

What changed is the (addition of a) definition of LAPACK_FORTRAN_STRLEN_END in lapack.h for when you call LAPACK functions directly from your C code, instead of through LAPACKE. This was added to expose the hidden/implied string length arguments that most/all Fortran compilers expect to be present, as Fortran does not use NULL-termination of strings like C does.
(The original issue was #339 - though what prompted it was largely a behaviour change in gfortran alone that got mitigated again in later releases. And while practically all Fortran compilers require additional length arguments for C strings, the controversy is/was about whether single-character arguments are exempt)

[martin-frbg]

(I do wonder what this means for compatibility with both past and alternative implementations (MKL?), and why it was not mentioned in the release notes for 3.10.0)

[yurivict]

I wonder who is going to be fixing software that used these functions (ex. treekin) which doesn't have active devs now.

[yurivict]

Legacy functions should be left in the library for the older software to use.
They should be left at least with the "_legacy" suffix.

[weslleyspereira]

Hi. The old interface should still work if you remove these lines:

lapack/LAPACKE/include/lapack.h

Lines 16 to 19 in 3b26987

	/* It seems all current Fortran compilers put strlen at end.
	* Some historical compilers put strlen after the str argument
	* or make the str argument into a struct. */
	#define LAPACK_FORTRAN_STRLEN_END

Did you (Could you please) try it?

[yurivict]

Hi. The old interface should still work if you remove these lines:

This seems to require lapack to be rebuilt with these lines removed. Other packages need to use the pre-built lapack package, one for all.

[weslleyspereira]

I'm not sure you need to rebuild LAPACK only because of those lines. We only use LAPACK_FORTRAN_STRLEN_END in lapack.h, which is a header file. Mind that this (optional) flag improves the compatibility between the C code and the library generated by most Fortran compilers. Please see #515 and the references therein for the discussion about it. Also, see #561, for the systematic use of this flag in LAPACKE.

[martin-frbg]

Having to modify a "system/distribution preinstalled" header depending on whose source you want to compile against LAPACK is not ideal either, I wonder if it would be possible to create a truly variadic prototype that would match both "traditional" and "pedantic" use ?

[yurivict]

This line:

      ::dsyevx_((char *)jobz, (char *)range, (char *)uplo, n, (double *)a, lda, (double *)vl,
              (double *)vu, il, iu, (double *)abstol, m, (double *)w,
              (double *)z, ldz, (double *)work, lwork, iwork, ifail, info);

breaks with:

./calcpp.h:317:74: error: too few arguments to function call, expected 23, have 20
              (double *)z, ldz, (double *)work, lwork, iwork, ifail, info);
                                                                         ^

and this line

      ::dgeevx_((char *)balanc, (char *)jobvl, (char *)jobvr, (char *)sense, n, (double *)a, lda,
              (double *)wr, (double *)wi, (double *)vl, ldvl,
              (double *)vr, ldvr, ilo, ihi, (double *)scale, (double *)abnrm, (double *)rconde,
              (double *)rcondv, (double *)work,
              lwork, iwork, info);

breaks with

./calcpp.h:373:33: error: too few arguments to function call, expected 27, have 23
              lwork, iwork, info);
                                ^

Any idea how to patch them?

[martin-frbg]

You'd need to add an "int" after the "info" parameter for each "char*" argument in the list. But I am not sure how portable that is with respect to earlier or alternative implementations of LAPACK:

[christoph-conrads]

You'd need to add an "int" after the "info" parameter for each "char*" argument in the list.

This depends on the compiler and in the case of gfortran also on the gfortran version!

The GNU Fortran Compiler 11.2.0 Documentation: Argument passing conventions:

For arguments of CHARACTER type, the character length is passed as a hidden argument at the end of the argument list. For deferred-length strings, the value is passed by reference, otherwise by value. The character length has the C type size_t (or INTEGER(kind=C_SIZE_T) in Fortran). Note that this is different to older versions of the GNU Fortran compiler, where the type of the hidden character length argument was a C int.

gfortran 7 expected a hidden int argument, see the The GNU Fortran Compiler 7.5.0 Documentation: Argument passing conventions.

[haampie]

So what's the best solution for the many C/C++ projects out there that expect the old API without the trailing string lengths? Always use LAPACKE? Use the LAPACK_[lapack function] macro everywhere?