FindBLAS first tries to locate the BLAS libraries by using pkg-config. However, instead of trusting the returned information, it then tries to locate all libraries given in the returned string within the returned library directory. When on Gentoo ACML is selected to provide BLAS, this strategy fails, because apart from the acml libraries, libgfortran and libpthread are reported by phk-config and these libraries are not located within the given library directory, since they are in the default library search path. Reproducible: Always Steps to Reproduce: 1. eselect blas set acml-gfortran-openmp 2. Add to CmakeLists.txt: FIND_PACKAGE(BLAS) 3. run cmake Actual Results: Make Error at /usr/share/cmake/Modules/FindBLAS.cmake:58 (message): Something is wrong in your pkg-config file - lib gfortran not found in /opt/acml4.4.0/gfortran64_mp/lib Expected Results: cmake runs without error since a blas implementation was found Instead of searching for the libraries, FindBLAS should either just trust pkg-config, or try to link a simple program that requires a BLAS function. The Bug was first reported upstream, were I was told that this is a purely Gentoo specific issue: http://www.cmake.org/Bug/view.php?id=13834
Could you please re-open the upstream bug (since they do not allow comments on closed bugs)? I don't know who said the statement they are quoting, but we are always keen to work with upstream to integrate our patches. > In fact I asked the Gentoo folks to push that fix upstream I am happy to personally work with upstream to ingrate the patch in question (as well as any of the many others we unfortunately are keeping to ourselves.)
Reopened upstream as requested.
This is a purely Gentoo issue since we replace FindBLAS.cmake.
We had several updates on cmake and the patch in meantime. Is this still valid?
(In reply to Johannes Huber from comment #4) > We had several updates on cmake and the patch in meantime. Is this still > valid?
