[Trilinos-Users] BLAS/LAPACK automatically linked by compiler

[Eric Bavier]

Setting the TPL_BLAS_LIBRARIES variable does not short-circuit the logic 
in the TPL library declaration code (TribitsTplDeclareLibraries.cmake), 
so it continues to search for the libraries named in FindBLAS.cmake.

What is possible however is to define TPL_BLAS_LIBRARY_NAMES:STRING="", 
an override that is "documented" in a comment in 
TribitsTplDeclareLibraries.cmake.  So, doing the following should work:

-D TPL_ENABLE_BLAS:BOOL=ON
-D TPL_BLAS_LIBRARY_NAMES:STRING=""

`~Eric


On 09/10/2012 01:06 PM, Antonio Cervone wrote:
> from Trilinos10CMakeQuickstart.txt:
>
> NOTE: The variables TPL_<TPLNAME>_INCLUDE_DIRS and TPL_<TPLNAME>_LIBRARIES
>    are what are directly used by the CMake build infrastructure.  These
>    variables are normally set by the variables <TPLNAME>_INCLUDE_DIRS,
>    <TPLNAME>_LIBRARY_NAMES, and <TPLNAME>_LIBRARY_DIRS using find commands but
>    you can always override these by setting the (type FILEPATH) cache
>    variables TPL_<TPLNAME>_INCLUDE_DIRS and TPL_<TPLNAME>_LIBRARIES.  This gives
>    the user complete and direct control in specifying exactly what is used in
>    the build process.  The other variables that start with <TPLNAME>_ are just a
>    convenience to make it easier to specify the location of the libraries.
>
> it seems that the user has not the desired "complete and direct control" :D
>
> try adding FILEPATH, it can be important
>
> -D TPL_BLAS_LIBRARIES:FILEPATH=""
>
> this way cmake has no other choice then to set that variable as you asked.
>
> antonio
>
> On Mon, Sep 10, 2012 at 7:45 PM, Nico Schlömer <nico.schloemer at gmail.com> wrote:
>> Hm. Doing this
>>
>>    -D TPL_ENABLE_BLAS:BOOL=ON \
>>        -D TPL_BLAS_LIBRARIES="" \
>>
>> yields this
>>
>> -- Processing enabled TPL: BLAS
>> --   Searching for library 'blas' ...
>> --   Searching for library 'blas_win32' ...
>> --   Warning: Could not find a library in the set "blas blas_win32"
>> for the TPL BLAS!  Please manually set BLAS_LIBRARY_DIRS and/or
>> BLAS_LIBRARY_NAMES or just TPL_BLAS_LIBRARIES to point to the BLAS
>> libraries!
>>
>> --Nico
>>
>> On Mon, Sep 10, 2012 at 6:02 PM, Antonio Cervone <ant.cervone at gmail.com> wrote:
>>> hi Nico,
>>> one way to go around this problem is to explicitly set the internal
>>> variable that tribits uses to link the library, i.e.
>>>
>>> TPL_BLAS_LIBRARIES
>>> TPL_BLAS_INCLUDE_DIRS
>>>
>>> if you set them to empty you should avoid the double linking.
>>> bye
>>>
>>> antonio
>>>
>>>
>>>
>>> On Mon, Sep 10, 2012 at 5:54 PM, Nico Schlömer <nico.schloemer at gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> here's a funny compiler issue.
>>>> On NERSC, the BLAS and LAPACK libraries are automatically included on
>>>> the link line by their compiler wrappers, much like libmpi.a is
>>>> automatically linked on many other platforms.
>>>> We've got outselves a little bit of a conflict of responsibilities
>>>> here since also CMake tries to care of BLAS and LAPACK, e.g.,
>>>>
>>>> -D TPL_ENABLE_BLAS:BOOL=ON \
>>>>        -D BLAS_LIBRARY_DIRS:FILEPATH="$CRAY_LIBSCI_PREFIX_DIR/lib" \
>>>>        -D BLAS_LIBRARY_NAMES="sci_gnu" \
>>>>
>>>> The exact library locations aren't officially disclosed, so at best
>>>> I'm getting BLAS and LAPACK implicitly twice on the link line. Should
>>>> they decide to change their BLAS/LAPACK directories in the wrappers
>>>> one day, however, this'll lead to two different BLAS/LAPACK libraries
>>>> on the link line which is less than ideal.
>>>>
>>>> What's the situation on other HPCs, and how do you deal with this?
>>>>
>>>> --Nico
>>>>
>>>> _______________________________________________
>>>> Trilinos-Users mailing list
>>>> Trilinos-Users at software.sandia.gov
>>>> http://software.sandia.gov/mailman/listinfo/trilinos-users
>>>>
>
> _______________________________________________
> Trilinos-Users mailing list
> Trilinos-Users at software.sandia.gov
> http://software.sandia.gov/mailman/listinfo/trilinos-users
>