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

[Nico Schlömer]

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
>