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

[Perschbacher, Brent M]

Nico,
  He is suggesting a slightly different variable. The one Eric suggested is
one way to allow Trilinos to find tpls that have been installed as a
different set of libraries than we set our tpl to expect. I'm not sure how
the empty string will behave here, but if adding the FILEPATH specifier to
TPL_BLAS_LIBRARIES doesn't fix it for you telling the cmake build to look
for a blank set of libraries might be another way to avoid actually looking
for blas.

If none of those work then Chris Bakers suggestion of using the cray env
variables is probably the best fallback.

Brent


On 9/10/12 12:50 PM, "Nico Schlömer" <nico.schloemer at gmail.com> wrote:

> Wait, what exactly do you have to specify?
> Just this
> 
>> -D TPL_ENABLE_BLAS:BOOL=ON
>> -D TPL_BLAS_LIBRARY_NAMES:STRING=""
> 
> won't work since CMake will complain about not being able to find BLAS.
> 
> --Nico
> 
> 
> 
> On Mon, Sep 10, 2012 at 8: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