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 _______________________________________________ Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
