[CMake] findAtlas cmake

[Michael Wild]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/2010 05:10 PM, luxInteg wrote:
> On Wednesday 03 November 2010 05:37:45 Michael Wild wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi
>>
>> On 11/03/2010 12:48 AM, luxInteg wrote:
>>> Greetings,
>>>
>>> I am a  novice  at cmake  and   attempting to compile lapack-3.2.2 on a
>>> computer with these:-
>>> ---cpu amd64 2 cores
>>> ---BLAS: atlas3.9.26 in /usr/local/atlas
>>> ---gcc-4.2.2/gfortran cmake-2.8
>>>
>>>
>>> here is a list of algebra stuff in /usr/local/atlas/lib
>>> root [ ~ ]# ls /usr/local/atlas/lib
>>> libacml_mp.so  libatlas.a   libcblas.a   libf77blas.a    libptcblas.a
>>> libptf77blas.a
>>> libacml_mv.so  libatlas.so  libcblas.so  libf77blas.so   libptcblas.so
>>> libptf77blas.so
>>> root [ ~ ]#
>>>
>>>
>>>
>>> There is a FindBLAS module in ~share/cmake-2.8/modules  but no search
>>> paths are set   for  linux.
>>
>> That's not necessary, since CMake searches the common locations on its
>> own. Now, /usr/local would be common, but not /usr/local/atlas.
>>
>>> And as a complete ignoramous  I cannot see anywhere one could poke one.
>>
>> Set the environment variable CMAKE_PREFIX_PATH to /usr/local/atlas
>> before you run CMake. This tells CMake to first go look in
>> /usr/local/atlas, and only then consider all the other default locations.
>>
> Thanks a lot.   I set CMAKE_PREFIX_PATH and  'BLAS" was fuind.
> 
> HOWEVER I have the foollowing in /usr/local/atlas/lib.  
> 
> rt [ ~ ]$ ls /usr/local/atlas/lib
> libacml_mp.so  libatlas.a   libcblas.a   libf77blas.a    libptcblas.a   
> libptf77blas.a
> libacml_mv.so  libatlas.so  libcblas.so  libf77blas.so   libptcblas.so  
> libptf77blas.so
> rt [ ~ ]$ 
> 
> Do you (or others on list know if  ALL  of these are  'found'  by  
> FindBLAS.cmake?  I am asking this as  I have applications downstream 
> that require linking to  -latlas -lf77blas and -lptf77blas  while others  the 
> cblas(es).  A related question also IS:- does one need to set the LDFLAGS 
> envar to be able to  set  "target_lib_libraries( -lxxx -lyyy )"  or are those 
> invoked by a successful application fo FindBLAS.cmake ?  
> 

If you do it like this

set(BLA_VENDOR ATLAS)
find_package(BLAS REQUIRED)

you tell FindBLAS.cmake to only look for atlas. Then the variable
BLAS_LIBRARIES will also contain also libatlas.a. However, linking
against both, libf77blas.a and libptf77blas.a at the same time is bogus.
The linker will only use functions from libf77blas.a, the threaded
implementations in libptf77blas.a will be ignored. If you happen to use
shared libraries instead, this would be a linking error.

Unfortunately, FindBLAS.cmake is currently not able to find the threaded
libraries. There seem to be other things wrong with it too, because it
tries to find cblas_dgemm with a Fortran compiler which is almost
certainly going to fail (due to Fortran name-mangling). At least on my
Ubuntu box FindBLAS.cmake is completely broken when it comes to ATLAS.

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzS2IUACgkQyAe0BK8NufOjAQCdErthQxOpbm/J3ceXXpWkvuMf
heMAn0cIR4U9Uc07oCiiblLpQecEqVjm
=dqYv
-----END PGP SIGNATURE-----