> On Oct 27, 2015, at 7:50 AM, Thiago Milanetto Schlittler > <thiago...@gmail.com> wrote: > > Hello! > > 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. How can I “convince” libMesh, during the configure > step, to use the MPI libraries found at /opt/local/lib/openmpi-mp ? I’m > already using the option "--with-mpi=/opt/local/libexec/openmpi-mp”, to > indicate where the proper compiler wrappers are.
I don't think you can, at least not easily. This is another manifestation of the problem we had with libcurl bringing in /usr/lib on the link line, and allowing other libs (in that case a wrong version of libstdcxx) to take precedence. However this case is more tricky, as it implies if we reorder lib dirs, we also need to worry about /usr/local/lib, and possibly others... Do you know what installed the MPI in /usr/local? If you could temporarily uninstall that, it might fix the problem. ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
