LAPACK++ may fail to link with LAPACK 3.9.1 - 3.11.0

[weslleyspereira]

Since Reference-LAPACK/lapack@628a209#diff-1710d7e7dbbb424e47de31c4995c3decf85025b77051f0ed0cb835988aeebe92, LAPACK defines LAPACK_FORTRAN_STRLEN_END in the header file lapack.h. As a consequence of that, LAPACK_dpstrf() requires an additional parameter that indicates the size of the string uplo. This routine is used in config/lapack_pstrf.cc that is called in LAPACKFinder.cmake:

lapackpp/cmake/LAPACKFinder.cmake

Lines 121 to 139 in 62680a1

	# Try to link and run LAPACK routine with the library.
	try_run(
	run_result compile_result ${CMAKE_CURRENT_BINARY_DIR}
	SOURCES
	"${CMAKE_CURRENT_SOURCE_DIR}/config/lapack_pstrf.cc"
	LINK_LIBRARIES
	# Use blaspp_libraries instead of blaspp, when SLATE includes
	# blaspp and lapackpp, so the blaspp library doesn't exist yet.
	# Not "quoted"; screws up OpenMP.
	${lapack_libs} ${blaspp_libraries}
	COMPILE_DEFINITIONS
	${blaspp_defines}
	COMPILE_OUTPUT_VARIABLE
	compile_output
	RUN_OUTPUT_VARIABLE
	run_output
	)
	debug_try_run( "lapack_pstrf.cc" "${compile_result}" "${compile_output}"
	"${run_result}" "${run_output}" )

When trying to build with LAPACK 3.11.0, I got the error:

At line 141 of file /home/weslleyp/storage/lapack/SRC/dpstrf.f
Fortran runtime error: Actual string length is shorter than the declared one for dummy argument 'uplo' (-4096/1)

I am using a Ubuntu machine with:

• GCC 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.2).
• LAPACK: current master (ae2f14fe1f0dd94b2dacc1c35107f0ea5b5c6f07)
• LAPACK++: v2023.08.25 (62680a1)
• BLAS++: v2023.08.25 (f8f983d5b45a8f366aae41fbe9888b14cbae20f8)

Please, let me know if I can give you more details.

[weslleyspereira]

A related comment: Since now BLAS++ depends on LAPACK, maybe LAPACK++ does not need to search for the LAPACK package anymore.

[mgates3]

Yes, we can fix this.

Pretty sure it's an issue with the Fortran compiler, not with LAPACK itself. Fortran has always required the string length, just very commonly when calling LAPACK from C we were ignoring it. Now the compiler is being more picky about it.

BLAS++ uses LAPACK only in the testers, and it requires a small subset of LAPACK, e.g., potrf but not pstrf. Though I feel like it would be better to move [cz]symv and [cz]syr to BLAS++, which would then make LAPACK a hard dependency.