On 07/19/2010 08:43 PM, Brad King wrote:
Note that if you use the *shared* libblas.so and liblapack.so then you do not need to list the implementation dependencies explicitly. Another way to view this is that when you pointed Trilinos at the blas and lapack libraries to use, you chose the static ones but did not mention their dependencies. This is where the manual interference comes in.
This may not be true everywhere or forever...Actually this feature is being dropped in future fedora releases (starting from F13 or F14 I do not remember), as it is seen as a security improvement (each app developper/packager now has to know explicitely all the libraries that need to be linked with his code).
I do not know yet if other distributions will follow (or have already followed) the same path...
By the way, somewhat related to this discussion, I have a modified version of the FortranCInterface.cmake that introduces a way of testing Fortran mangling from an existing library (so that there is no need to specify fortran as a language for cmake). This was discussed on this list in January. I'm sure it is not
perfect but it works quite well for us.I thus take the opportunity of posting it here for comments, advices or for people to use it.... It may need for some adjustements depending on where you install it (see FortranCInterface_SOURCE_DIR). It introduces a FROM_LIBRARY parameter that modifies the behaviour of the macro
FortranCInterface_HEADER Usage:FortranCInterface_HEADER(FC.h MACRO_NAMESPACE "FC_" FROM_LIBRARY blas[daxpy])
This checks the fortran mangling from the function daxpy in the blas library....
Theo.
FortranCInterface.tgz
Description: application/compressed-tar
_______________________________________________ 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
