On Tue, 27 Oct 2015, Thiago Milanetto Schlittler wrote:
Hum, I think it’s a linker problem … otool -L (forgot about this
tool …) returns that the linked MPI libraries are inside the
/usr/local/lib/ folder, while the libraries created by the macports'
openmpi are located at /opt/local/lib/openmpi-mp …
I’ve copied the summary file below. What’s really weird now is that the
/opt/local/lib/openmpi-mp is given as part of the library path:
libmesh_optional_LIBS............ : [ … ] -L/opt/local/lib/openmpi-mp [ … ]
-Wl,-rpath,/opt/local/lib/openmpi-mp [ … ]
So, the system is choosing to prioritise the libraries found inside the
/usr/local/lib/ folder.
Not quite. That is a common libMesh problem for people who have
multiple incompatible library versions installed: you tell it to use
one library from e.g. /usr/lib or /usr/local/lib, so it puts that
directory in your linker path, so your linker finds *other* libraries
there too.
But it looks like that's not your problem - I don't see /usr/local/lib
in your libMesh linker arguments at all.
In my experience on Linux, that usually means you're getting the
unwanted library indirectly: you deliberately link to library X, and
it has an rpath set up to make sure it loads a particular version of
its own dependency library Y. I don't know how OSX dynamic linker
pathing works, though, and I don't know how to learn more other than
by going down the "otool -L" output one library at a time and checking
the dependencies of each.
---
Roy
------------------------------------------------------------------------------
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
