[CMake] findAtlas cmake

[luxInteg]

On Thursday 04 November 2010 16:00:05 Michael Wild wrote:
> -----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.
> 
thanks for the info