LAPACK compilation with gfortran

[miEsMar]

Hi everyone,

so this is getting me quite puzzled.
I've already built LAPACK from source many times, on different platforms, including Windows.
I have now switched to another Linux machine, with gfortran GNU Fortran (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0.
This is the generation script:

cmake \
   -D CMAKE_INSTALL_PREFIX=./install \
   -D CMAKE_BUILD_TYPE=Release \
   -D CMAKE_Fortran_COMPILER=gfortran \
   -D TEST_FORTRAN_COMPILER=ON \
   -D BUILD_SHARED_LIBS=ON \
   -D BUILD_INDEX64=ON \
   -S . -B ${build_dir}

Everything builds correctly, except that I notice that in both BLAS and LAPACK object files, symbols names have a trailing _.
This was a convention adopted by gfortran when it came to Fortran-C interop before this was standardised, with the bind() method.
However, the issue here is that neither BLAS or LAPACK are to be linked with C interface, since that is for CBLAS and LAPACKE, which are not built. Also, I see that there is also in fact among the preprocessing options, the case where symbols are exported without the trailing _.
So, I cannot figure out why is this happening.

[miEsMar]

So, the "workaround" I implemented was to add in the top-level CMakeLists.txt:

enable_language(Fortran)
include(CheckFortranCompilerFlag)
check_fortran_compiler_flag("-fno-underscoring" _gf_no_underscore)
if(_gf_no_underscore)
  set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -fno-underscoring")
endif()

right before BLAS and LAPACK subdirectories are sourced.

However, I strongly doubt this is the way to make it work.

[martin-frbg]

I'm fairly sure the trailing underscore is a platform default for gfortran on Linux, and the compiler cannot guess what you might want to link against the library in the future, regardless whether you built CBLAS/LAPACKE or not ?

[miEsMar]

OK, this is now getting even more confusing and weird.
Out of curiosity, I checked in another system (Linux RedHat 9.2) where I was able to compile and run the tool I am working on, which uses LAPACK.
So, this means I am referring to the same CMakeLists.txt file I am using on the previously mentioned system, which fails at the find_package( LAPACK ) function.
Running nm -a liblapack.a | grep "T sgem" shows that acutally, all symbols in the Text section have the trailing underscore.
But, so why didn't the check for the sgemm fortran function fail, as it does in this case?

[miEsMar]

At this point, I start doubting is a LAPACK related issue, while is more of the Fortran Language support in CMake versions..

[martin-frbg]

How is your check for sgemm coded, wouldn't the compiler add a trailing underscore there as well ? Also SGEMM is BLAS rather than LAPACK, so there is a non-zero chance (especially with distribution-provided binaries) that your test does not actually find the liblapack you desire (unless it is actually BLAS you are after). Indeed I doubt that this is fundamentally a Reference-LAPACK issue...

[miEsMar]

That's the point, to which I agree.
The search is done with the CMake built-in module CheckFortranFunctionExists.cmake, so the mangling convention should be the same for both the Reference-LAPACK compilation, and my tool which uses it.
But that seems to not be working as expected on this particular system.
The only reasonable thing I can think of is that I am not actually pointing to the right Reference-LAPACK installation directory, since it is not installed at the system level.
But I almost read the whole FIndLAPACK.cmake and FindBLAS.cmake, without finding how to tell CMake where to look..

PS: I did refer to LAPACK as a whole, indeed sgemm* belong to BLAS. But thanks for pointing out.

[miEsMar]

Ok, at the generation stage, adding the flags

    -D BLAS_LIBRARIES="~/repos/lapack/install/lib/libblas64.a" \
    -D LAPACK_LIBRARIES="~/repos/lapack/install/lib/liblapack64.a" \

fixed the issue.
I still wonder how to tell CMake just the installation directory (or. maybe the lib dir?), instead of needing to provide the whole path the the library files directly. Maybe this is a FindLAPACK/BLAS.cmake limitation.