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

[Nico Schlömer]

Setting

  -D BLAS_LIBRARY_NAMES:STRING="" \
  -D LAPACK_LIBRARY_NAMES:STRING="" \

indeed nicely makes CMake ignore the fact that it doesn't know just
where BLAS/LAPACK are located.

However, further down in the CMake logic we have some code that tries
to tell just what LAPACK is capable of:

=========== *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
-- * TPL_LAPACK_LIBRARIES = -L/global/homes/n/nschloe/pkg/lapack-3.2.1
-llapack -ltmglib
-- TPL_BLAS_LIBRARIES = -L/usr/lib64 -lblas: building inside Trilinos
-- TPL_LAPACK_LIBRARIES = -L/global/homes/n/nschloe/pkg/lapack-3.2.1
-llapack -ltmglib: building inside Trilinos
-- Using previously set TPL_{BLAS,LAPACK}_LIBRARIES
-- * TPL_BLAS_LIBRARIES = -L/usr/lib64 -lblas
-- * TPL_LAPACK_LIBRARIES = -L/global/homes/n/nschloe/pkg/lapack-3.2.1
-llapack -ltmglib
-- Checking LAPACK QR factorization routine names
-- Checking whether your LAPACK library includes DLARFG
-- Performing Test HAVE_LAPACK_DLARFG
-- Performing Test HAVE_LAPACK_DLARFG - Failed
[...]
=========== *snap* ===========

I'm not sure at all *what* it's picking up there ("-L/usr/lib64
-lblas" doesn't exist, for example). Anyways, this seems like
something one wouldn't want to see. Eric?

--Nico



On Mon, Sep 10, 2012 at 9: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
>