[Trilinos-Users] Space-separated TPLs link options

[Perschbacher, Brent M]

Hello Alberto,
  This is one of the more interesting issues that we've run into with
libraries. MKL unfortunately has circular dependencies in some of its
libraries, and generally that is not something we support largely because of
the issues that are caused by those kinds of dependencies. There have been a
couple of workarounds, one of which it looks like you are trying to use.
However, that particular work around has side effects that cause the export
systems (cmake or makefile) to not work properly. If you aren't using either
of the export systems then you should be able to get working simply by
quoting the $BLAS_LIB shell variable when you use it. ie:
-D TPL_BLAS_LIBRARIES:STRING="$BLAS_LIB" \

This will fix the issues with the spaces that are in BLAS_LIB.

A more robust work around is to set the libraries similar to what you have,
only in a cmake way. The following is a snippet from a configure script
using MKL

-DTPL_LAPACK_LIBRARIES:STRING="$MKL_PATH/libmkl_lapack95_lp64.a" \
-DTPL_BLAS_LIBRARIES:STRING="$MKL_PATH/libmkl_intel_lp64.a;$MKL_PATH/libmkl_
sequential.a;$MKL_PATH/libmkl_core.a" \
-DTrilinos_EXTRA_LINK_FLAGS:STRING="-L$MKL_PATH -lmkl_intel_lp64
-Wl,--start-group -lmkl_intel_thread -lmkl_core -Wl,--end-group -lguide
-lpthread" \

Where $MKL_PATH was the path to where MKL had been installed on this machine

This version is slightly more cumbersome because of the reliance on the
Trilinos_EXTRA_LINK_FLAGS variable, however as I recall this method did not
cause problems with the export system since the TPL_BLAS_LIBRARIES variable
was set to actual libraries and not options to pass to the linker. Instead
the options that had to be passed to the linker were instead put in
Trilinos_EXTRA_LINK_FLAGS.

The root of the problem is the -Wl,--start-group ... -Wl,--end-group that is
required by MKL. Our tpl system was not designed to support tpls that
require options to the linker to be intermingled with their libraries. You
can put them in the TPL_<name>_LIBRARIES variable and have it work for
building Trilinos, but that is only because when that variable is set we
take that to mean "use exactly what we've been told" and when it is passed
to the linker it tends to work out. However, when we use those variables
internally assumptions about them can be broken when they are set by the
user.

Let us know if neither of the above solutions worked for you.

Brent


On 6/30/11 12:11 PM, "Alberto F. Martín-Huertas" <amartin at cimne.upc.edu>
wrote:

>  Dear All,
> 
>  I would like to know which CMake macros I have
>  to set (and how a I have to set them)
>  in order to link against TPLs in case of
>  space-separated link options, like the following ones:
> 
>  #Setting defitions for MKL BLAS
>  BLAS_DIR="/opt/intel/Compiler/11.0/084/mkl"
>  BLAS_LIB="-L$BLAS_DIR/lib/em64t -lmkl_solver_lp64_sequential \
>            -Wl,--start-group -lmkl_intel_lp64 -lmkl_sequential
>  -lmkl_core -Wl,--end-group -lpthread"
> 
>  Currently, I am using the following CMake macros without success
>  (in particular, only the first token of $BLAS_LIB is copied to the
>   CMakeCache variable TPL_BLAS_LIBRARIES:STRING):
> 
>       -D TPL_ENABLE_BLAS:BOOL=ON \
>       -D TPL_BLAS_LIBRARIES:STRING=$BLAS_LIB \
>       -D TPL_ENABLE_LAPACK:BOOL=ON \
>       -D TPL_LAPACK_LIBRARIES:STRING=$BLAS_LIB \
> 
> 
>  Thanks in advance.
> 
>  Best regards,
>   Alberto.
> 
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at software.sandia.gov
> http://software.sandia.gov/mailman/listinfo/trilinos-users