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

[Phipps, Eric T]

Here' what I have done in this situation (e.g., Cray platforms), and it
works:

-D TPL_BLAS_LIBRARIES="" \
-D BLAS_LIBRARY_NAMES="" \

-Eric



On 9/10/12 1:12 PM, "Perschbacher, Brent M" <bmpersc at sandia.gov> wrote:

>Actually, setting TPL_<tpl name>_LIBRARIES explicitly does short circuit
>the
>logic of our current tpl system. However, I don't think we've every really
>tested that the empty string will behave as expected here.
>
>As Antonio pointed out the FILEPATH may be necessary in this case. What is
>done in our tpl system is to check to see if TPL_<tpl name>_LIBARIES is
>already set, if it is we assume it was set correctly and use it verbatim.
>However, if you leave it up to cmake to determine what the type of that
>variable is it may confuse us. An empty string for a STRING variable in
>cmake is false if you do a simple test like "if(TPL_<tpl_name>_libraries)"
>which is how we test to see if the user set the variable. I haven't tried
>setting these variables to the empty string myself, but it is possible
>that
>to cmake a FILEPATH variable that is the empty string is not false.
>
>Brent
>
>
>On 9/10/12 12:29 PM, "Eric Bavier" <bavier at cray.com> wrote:
>
>> 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
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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