Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#66453 - [openblas] /usr/lib/libblas.so.3.9.0 missing to properly reblace blas package

Attached to Project: Community Packages
Opened by Michael Laß (Bevan) - Tuesday, 28 April 2020, 18:01 GMT
Last edited by freswa (frederik) - Tuesday, 28 April 2020, 18:29 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

Description:

openblas can be installed as a replacement for blas. However, doing so causes an issue with CMake: Using CMake to link software against CBLAS or LAPACK, it tries to link in /usr/lib/libblas.so.3.9.0. However that file is only included in blas and not in openblas. This leads to the following error message:

--snip--
CMake Error at /usr/lib/cmake/lapack-3.9.0/lapack-targets.cmake:93 (message):
The imported target "blas" references the file

"/usr/lib/libblas.so.3.9.0"

but this file does not exist. [...]
--snip--

The problem can easily be solved by creating a symlink from /usr/lib/libblas.so.3.9.0 to /usr/lib/libopenblasp-r0.3.9.so. Doing so in the openblas package would however require updating it everytime blas/cblas/lapack get updated.

Package version: 0.3.9-1
This task depends upon

Comment by Marcell Meszaros (MarsSeed) - Wednesday, 23 February 2022, 13:39 GMT
Cannot reproduce. The information is insufficient to verify possible edge cases or downstream-specific issues.

Also, cblas and lapack packages link against the major API version of BLAS: libblas.so.3, as is the norm.

Therefore I suggest the issue is either already fixed, or was an issue with your unnamed downstream project's build source.
Comment by Michael Laß (Bevan) - Wednesday, 23 February 2022, 14:00 GMT
Well, I don't know anymore what downstream project I tried to build at that time. But I'm confident the issue is still there by looking at the provided files:

lapack-3.10.0-1-x86_64.pkg.tar.zst contains /usr/lib/cmake/lapack-3.10.0/lapack-targets-release.cmake which references libblas.so.3.10.0 in line 11.

libblas.so.3.10.0 is provided by the blas package but not by the openblas package which only contains libblas.so.3.
Comment by Marcell Meszaros (MarsSeed) - Wednesday, 23 February 2022, 14:37 GMT
Hey, thanks for your answer.

I've looked into the file and still cannot verify the suggested problem.
In lapack-3.10.0-1-x86_64 package: usr/lib/cmake/lapack-3.10.0/lapack-targets-release.cmake: line 11-12-13*:
//--edit: my mistake; quote is from usr/lib/cmake/cblas-3.10.0/cblas-targets-release.cmake //:

IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE "blas"
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libcblas.so.3.10.0"
IMPORTED_SONAME_RELEASE "libcblas.so.3"

It does not refer to the versioned libblas.so, only its own CBLAS-specific libcblas.so.3.10.0.

No sign of any issues.

It is important that you provide exact logs or other clear evidence of build problems.

I hope this helps to move forward with this task. My suggestion is to close it as it is not actionable.
You can file a new bug report in the future with logs, if/when you experience the suggested issue.
Comment by Michael Laß (Bevan) - Wednesday, 23 February 2022, 15:18 GMT
curl -s -L https://archlinux.org/packages/extra/x86_64/lapack/download | tar xO usr/lib/cmake/lapack-3.10.0/lapack-targets-release.cmake | grep -n libblas.so.3.10.0
Output:
11: IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libblas.so.3.10.0"
16:list(APPEND _IMPORT_CHECK_FILES_FOR_blas "${_IMPORT_PREFIX}/lib/libblas.so.3.10.0" )

Could it be that you looked at cblas-targets-release.cmake from the cblas package instead?

curl -s -L https://archlinux.org/packages/extra/x86_64/cblas/download | tar xO usr/lib/cmake/cblas-3.10.0/cblas-targets-release.cmake|tail -n+11|head -n3
Output:
IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE "blas"
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libcblas.so.3.10.0"
IMPORTED_SONAME_RELEASE "libcblas.so.3"

Anyway, I'll try to come up with a reproducer as soon as I find time. Please leave this bug report open for now.
Comment by Antonio Rojas (arojas) - Wednesday, 23 February 2022, 16:27 GMT
One-line reproducer:

> cat CMakeLists.txt
find_package(lapack)

(side note: you can use find_package(LAPACK) (capitalized) instead, and it will use cmake's own module, which does not have this issue)
Comment by Marcell Meszaros (MarsSeed) - Wednesday, 23 February 2022, 16:32 GMT
@Bevan indeed, you are right, my mistake.

Now that is a clear evidence that the source of the problem is the package:
lapack-3.10.0-1-x86_64.pkg.tar.zst

That package should not contain explicit CMake build target configuration referring to a file it clearly doesn't own:

- lapack-3.10.0-1-x86_64.pkg.tar.zst owns:
usr/lib/cmake/lapack-3.10.0/lapack-targets-release.cmake

--> which refers to file inside package:

- blas-3.10.0-1-x86_64.pkg.tar.zst package, owns:
{usr/}lib/libblas.so.3.10.0

Aur/extra/lapack is a split package for blas, cblas, lapack-doc, lapacke.
Seems blas build target metadata got embedded in the wrong place: lapack's cmake import file.

Suggest to (re)file this as a [lapack] build/package bug. What do you guys think?
Comment by Michael Laß (Bevan) - Wednesday, 23 February 2022, 16:39 GMT
Sounds good to me. That would properly decouple lapack from blas/openblas.

Loading...