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

Perschbacher, Brent M bmpersc at sandia.gov
Mon Sep 10 15:45:11 MDT 2012 

Nico,
  It looks like that message is coming from
packages/kokkos/classic/NodeTSQR/cmake/TsqrBlasAndLapack.cmake

Mark, that looks like something you were working on. Can you comment on what
it is doing that would issue that message and if that would have any impact
on the build?

Brent


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

> I don't see an effect of
> 
>  -D TPL_BLAS_LIBRARIES="" \
> 
> here, but anyways
> 
>  -D BLAS_LIBRARY_NAMES="" \
> 
> makes configure finish without errors. Trilinos also builds fine (as
> far as I can tell), so if it weren't for those funny LAPACK/BLAS
> messages
> 
> =========== *snip* ===========
> [...]
> -- TPL_BLAS_LIBRARIES not defined: building outside Trilinos
> -- TPL_LAPACK_LIBRARIES not defined: building outside Trilinos
> -- Setting TPL_{BLAS,LAPACK}_LIBRARIES here, since they were not set already
> -- Assuming libraries live in subdirectories of PKG_DIR =
> /global/homes/n/nschloe/pkg
> -- -- Default system BLAS and custom LAPACK
> -- * TPL_BLAS_LIBRARIES = -L/usr/lib64 -lblas
> [...]
> =========== *snap* ===========
> 
> I'd be completely content. Chris, maybe you can let me know what this
> gives for you on Jaguar?
> 
> --Nico
> 
> 
> On Mon, Sep 10, 2012 at 9:19 PM, Phipps, Eric T <etphipp at sandia.gov> wrote:
>> 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
>> 
>> 
>> _______________________________________________
>> Trilinos-Users mailing list
>> Trilinos-Users at software.sandia.gov
>> http://software.sandia.gov/mailman/listinfo/trilinos-users
>> 
>

More information about the Trilinos-Users mailing list