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

[Perschbacher, Brent M]

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