2.2.2 installs lib/cmake/scalapack-2.2.1

[VictorEijkhout]

Like it says. Version number discrepancy between package version and directory for the .cmake files.

[ivr900]

Before running cmake, I do from scalapack-2.2.2 root directory

sed -i -e "/SCALAPACK VERSION/s/2.2.1/2.2.2/" CMakeLists.txt

[drhpc]

Yes, the version is just not updated to match the tag. On top of that … are those cmake files even helpful? I need to remove them to make another cmake-using package (octopus) build. It finds scalapack just fine using pkg-config.

Please consider a new release 2.2.3 with version numbers fixed, and ideally a separate tarball like before.

Also, I remember a discussion about the library soversion numbers that (needlessly?) break ABI on each minor release. I should raise separate issue about library compatibility, I guess.

[drhpc]

Btw.: I forgot to mention the acutal issue that breaks octopus build: There is an unresolved MPI::MPI_C in scalapack-targets.cmake:

  INTERFACE_LINK_LIBRARIES "/data/pkg/lib/libopenblas_openmp.so;/data/pkg/lib/libopenblas_openmp.so;/data/pkg/lib/libopenblas_openmp.so;MPI::MPI_C"

I am not versed enough in CMake to know if there should be a find_package(MPI) in that file or not. It smells wrong to have an unresolved token in there, though. As well as the exact library for openblas that has been used (observe the specific name), the correct MPI library needs to be mentioned, too.

But at least on a Unix system, this information is nicely available via pkg-config and I do not see a value in the added complexity of cmake files for the same purpose.

[LukasvdWiel]

Can confirm the fix, that replacing 2.2.1 in CMakeLists.txt fixed the naming of the project.

[VictorEijkhout]

@luszczek Is this package still maintained? I see no developer responses on multiple user comments here.

[luszczek]

I agree that ScaLAPACK might not be getting the same attention as LAPACK. I'll ask around to see what can be dome to improve the response rate.

[LecrisUT]

The original issue should be resolved with #124

@luszczek Is this package still maintained? I see no developer responses on multiple user comments here.

If there are CMake/build-system/CI questions, you can tag me and I can fill in any gaps. I sporadically do contributions on that front, but if there are some relevant issues, I can see if I can do some quick fixes.

Btw.: I forgot to mention the acutal issue that breaks octopus build: There is an unresolved MPI::MPI_C in scalapack-targets.cmake:

  INTERFACE_LINK_LIBRARIES "/data/pkg/lib/libopenblas_openmp.so;/data/pkg/lib/libopenblas_openmp.so;/data/pkg/lib/libopenblas_openmp.so;MPI::MPI_C"

Interesting. The issue is likely with

scalapack/CMakeLists.txt

Line 233 in a0f6ffe

target_link_libraries( scalapack ${LAPACK_LIBRARIES} ${BLAS_LIBRARIES} MPI::MPI_C)

The linkage is supposed to be PRIVATE. There is one caveat though. If a dependency is in the public headers or equivalents, it should be PUBLIC instead. I do not know if/when that is the case for this project, but if anyone can indicate that here or can improve the /EXAMPLE to cover some of the more practical usages, I can make a quick fix.

[VictorEijkhout]

Ok, I can now build an example:

find_package( MPI REQUIRED )
find_package( scalapack REQUIRED )

target_link_libraries(
        ${PROJECTNAME} PUBLIC
        scalapack
        ${LAPACK_LIBRARIES}
        ${BLAS_LIBRARIES}
        MPI::MPI_Fortran
        )

Thanks.

However the pkg config mechanism is still broken:

$ pkg-config --libs scalapack
Package mpi was not found in the pkg-config search path.
Perhaps you should add the directory containing `mpi.pc'
to the PKG_CONFIG_PATH environment variable
Package 'mpi', required by 'scalapack', not found
Package 'lapack', required by 'scalapack', not found
Package 'blas', required by 'scalapack', not found

[LecrisUT]

Ah yeah, pkg-config is more of a wild-west ecosystem. If all of the mpi, lapack and blas vendors have coordinated to provide an aliased virtual .pc files, those requires could be used, otherwise it would need to expand for the specific vendor that was used. But this is a very tricky issue because the pkg-config files might not have been used during the build.

Best solution I can suggest for a refactor is to drop the inter-pkg-config file linkage and use the pure cmake library flags that were used in the build in there. Note: it is an ugly beast to write that.

[VictorEijkhout]

I actually like pkg-config, because you can use it on the commandline and is not tied to cmake.

prefix=/work2/00434/eijkhout/scalapack/installation-scalapack-git-stampede3-intel25.1-impi21.15
libdir=/lib64

Name: scalapack
Description: SCALAPACK reference implementation
Version: 2.2.2
URL: http://www.netlib.org/scalapack/
Libs: -L -lscalapack
Requires: mpi lapack blas

1. Your Libs line is missing the directory name.
2. Deleting the requires line and supplying the mpi/blas/lapack explicitly works.
3. Aren't you assuming that any Blas provider make a b las.pc as opposed to specificblasimpl.pc?

[LecrisUT]

(I haven't touched those in my refactoring yet ;))

But yeah pkg-config would be very nice, but getting it right is a whole journey. I also see that it is not relocatable. I did have a note that there is a variable that can be used to make it relocatable.

3. Aren't you assuming that any Blas provider make a b las.pc as opposed to specificblasimpl.pc?

This one issue that it would be great to have some data on. How do each vendor do? Afaik pkg-config is static so you can't use variables like BLA_VENDOR to narrow it down.

That does raise another issue, doesn't the library have to link to the exact vendored dependency used in the build? This would affect how this is refactored. But conversely, are these genuine PUBLIC dependencies? I.e. are there missing symbols if these libraries are not included, and is it possible to track where these are coming from?

[drhpc]

In my world, I install several BLAS next to each other, and each installs its someblas.pc file. The plain blas.pc is either from the netlib reference or a symlink. I do not offer multiple MPIs in the same environment, but still I'd expect Open MPI to install openmpi.pc. Pkgconfig names should be unique. Distributions then can decide to rename/alias things. On Debian, you have the runtime switching of library symlinks to choose the system default blas --- with the possibly dangerous idea that all implementations are ABI compatible. In my builds on HPC systems, I want to be specific and have at runtime the libraries that were used at build time. Ideally, I tell things like ScaLAPACK which BLAS to use via pkg-config and it may hardcode that exact name in its .pc files. That is the named dependency. MPI is trickier, as that is not ordinarily just linked in as a library, but used via compiler wrappers. I'm not sure how widespread the existence of MPI pkg-config files is beteween vendors and if they are considered a valid alternative to calling mpicc and friends. For sure you don't want to mix implementations ... Then we have build variants to consider, like 64 bit indices (ilp64 BLAS/LAPACK). Right now, I install a blas64.pc (and openblas64.pc, along openblas64-openmp.pc, ...) in pkgsrc environments. If some pkg-config module was used in build, it shall appear in scalapack.pc, not some generic name. And it shall be fixed, IMHO, not some variable. Possibly there is a system that plugs in blas.pc as symlinks, some management of PKG_CONFGIG_PATH to have the same names mapped to differing libs. This is outside the scope of the scalapack build system. I do wonder how well-established mpi.pc or the like is. I did work a bit on making cmake locate BLAS stuff via pkg-config, not via its own cmake files stuff. I do like this build-system-agnostic path and would like it to be more common. Message ID: ***@***.***>