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

[John R Cary]

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 embedded and charset-unspecified text was scrubbed...
Name: FindTrilinos.cmake
Url: https://software.sandia.gov/pipermail/trilinos-users/attachments/20100708/fc08282f/attachment-0002.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TxFindPackage.cmake
Url: https://software.sandia.gov/pipermail/trilinos-users/attachments/20100708/fc08282f/attachment-0003.pl