[Trilinos-Users] How to get lapack/blas library consistency?

[Kurtis Nusbaum]

Was this issue ever resolved? I'm really curious as to what was going on.

-Kurtis

On Thu, Jul 8, 2010 at 8:31 AM, John R Cary <cary at colorado.edu> wrote:

> Hi Brent,
>
> Thanks for your help.
>
> Right now my issue is related to trilinos alone -- that
> the created shared objects resolve to libraries found
> first in /etc/ld.so.conf rather than the full paths I
> specified when configuring.  Once consistency is obtained,
> I think I then know how to make sure my application finds
> a lapack and blas consistent with what was used by trilinos.
>
> (BTW, I have a side benefit from all this in learning that
> my system had atlas installed at all.  I would always want
> this built locally so that it can do its autotuning magic.)
>
> I have not run any ifpack tests, but I have run tests with
> the combined application, and it seems that all is working
> okay.  But my combined application makes not direct use
> of lapack or blas; it uses them through only Trilinos, and
> so if Trilinos has a consistent resolution step, then this
> application will not have symbol collisions.  The worry is
> for other applications we build that make use lapack directly
> and then might have symbol collisions.
>
> Here are my machine and compiler:
>
> iter.cary$ uname -a
> Linux iter.txcorp.com 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 17:27:08
> EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
> iter.cary$ g++ --version
> g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
>
> Here is my trilinos configure line:
>
> cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/contrib/trilinos-10.2.0-ser
> -DCMAKE_BUILD_TYPE:STRING=RELEASE -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE
> -DCMAKE_C_COMPILER:FILEPATH='gcc' -DCMAKE_CXX_COMPILER:FILEPATH='g++'
> -DCMAKE_Fortran_COMPILER:FILEPATH='gfortran' -DCMAKE_C_FLAGS:STRING='-fPIC'
> -DCMAKE_CXX_FLAGS:STRING='-fPIC' -DCMAKE_Fortran_FLAGS:STRING='-fPIC'
> -DTrilinos_ENABLE_Amesos:BOOL=ON -DTrilinos_ENABLE_ML:BOOL=ON
> -DTrilinos_ENABLE_AztecOO:BOOL=ON -DTrilinos_ENABLE_EpetraExt:BOOL=ON
> -DTrilinos_ENABLE_Epetra:BOOL=ON -DTrilinos_ENABLE_Triutils:BOOL=ON
> -DTrilinos_ENABLE_Teuchos:BOOL=ON -DTrilinos_ENABLE_Ifpack:BOOL=ON
> -DTrilinos_ENABLE_Galeri:BOOL=ON -DTrilinos_ENABLE_Anasazi:BOOL=ON
> -DDART_TESTING_TIMEOUT:STRING=600 -DBUILD_SHARED_LIBS:BOOL=ON
> -DTrilinos_ENABLE_PyTrilinos:STRING=ON
> -DPyTrilinos_INSTALL_DIR:PATH=/usr/local/contrib/lib64/python2.6/site-packages/PyTrilinos
> -DTrilinos_EXTRA_LINK_FLAGS:STRING='-L/usr/lib/gcc/x86_64-redhat-linux/4.4.1
> -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.4.1'
> -DTPL_LAPACK_LIBRARIES:FILEPATH='/usr/lib64/liblapack.so'
> -DTPL_BLAS_LIBRARIES:FILEPATH='/usr/lib64/libblas.so'
> /scr_iter/cary/vpall/builds/trilinos
>
> which results in an inconsistency:
>
> iter.cary$ cd /usr/local/contrib/trilinos-10.2.0-ser
> iter.cary$ grep lapack TrilinosConfig.cmake
>
> SET(Trilinos_TPL_LIBRARIES "/usr/lib64/liblapack.so;/usr/lib64/libblas.so")
> iter.cary$ ldd lib/libifpack.so | grep lapack
>        liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3
> (0x00007f713a25e000)
>
> BTW, in case you are still curious about how we find trilinos,
> attached is our FindTrilinos.cmake file, which depends on our
> more general TxFindPackage.cmake file, but then tries to
> grep lapack and blas out of TrilinosConfig.cmake.
> (Our find-package methods rely on our particular
> installation methodology, which is to install packages
> in their own subdirs under some installation directory.)
> I went ahead and attached these as they are quite small.
> I hope that is okay.
>
> Thanks again.....John
>
>
>
> On 7/7/10 5:14 PM, Perschbacher, Brent M wrote:
>
>> John,
>> I think we are going to need more information to debug this. Can you
>> send your configure script and tell me what kind of a machine you are
>> building on, linux, mac, some cluster, etc. please?
>>
>> I find it interesting that your link line has –lblas as my machine has
>> always used an absolute path to blas/lapack whenever I have looked,
>> though I don’t build shared too often so that might be the difference.
>>
>> The fact that your atlas install is the first .conf file loaded is why
>> that is getting picked up for the lapack library since you only have a
>> –llapack and no matching –L for it. It also explains Now how to get
>> around that I’m not 100% certain. I don’t think that we have many test
>> machines that have multiple installations of blas and lapack which is
>> why we haven’t run into this before. Thankfully it is pretty easy to
>> fake having multiple installations of tpls so we should be able to mock
>> up a testing environment.
>>
>> I’m assuming that the ifpack tests link and run just fine and that your
>> issue is when you are trying to pull ifpack into your project is that
>> correct? If so can you explain what your project is doing to pull in
>> Trilinos and/or ifpack and how you are setting up your
>> compilers/flags/etc. Sending the files along would be fine too, so long
>> as they aren’t so large they get rejected by our email server. If you do
>> send files though you should send them just to me so we don’t clog the
>> user list with a lot of files.
>>
>> Thanks,
>>
>> Brent
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://software.sandia.gov/pipermail/trilinos-users/attachments/20100712/a02af998/attachment.html