Here's what the version numbers were for v1.5.3:
libmpi_so_version=1:1:0
libmpi_cxx_so_version=1:1:0
libmpi_f77_so_version=1:1:0
libmpi_f90_so_version=1:1:0
libopen_rte_so_version=2:0:0
libopen_pal_so_version=2:0:0
Here's what I think they should be for v1.5.4 -- can someone sanity check me?
lib
Please read and double check. Send any edits to me, or edit NEWS on the trunk
directly. Thanks.
- Add support for the (as yet unreleased) Mellanox MXM transport.
- Add support for dynamic service levels (SLs) in the openib BTL.
- Fixed C++ bindings cosmetic/warnings issue with
MPI::Comm:
Now I see the problem. The Open MPI binaries were build with Microsoft
cl compiler, it has different name conventions, so the symbols couldn't
be resolved by g++ compiler. I've started the native MinGW compiler
support, some projects can already be built via gcc or g++, but it's not
finished
Hi,
Which command did you use to compile your code?
I tried following code on my Windows 7 machine with compile command
"mpicxx hello.cpp":
hello.cpp
===
# include "mpi.h"
using namespace std;
int main ( int argc, char *argv[] )
{
int rank, size;
MPI::Ini
If all processes are coming out to be rank 0, it *may* mean that you're
dynamically linking to the wrong MPI library at run time, or have some other
kind of MPI implementation/version mismatch.
At least, it can mean this in a POSIX environment. I don't rightly know what
it means in a Windows
Hi Renyong,
If the same problem occurs under Linux, then the Boost.MPI library might
have compatible issues with Open MPI, but it still needs to be verified.
However, I'm also confused why the simple code didn't work for you. The
only guess is the environment is messed up by different MPI
im
Hi,
The code works for me under MinGW console with the pre-compiled
installer. Could you try "which mpicc" to ensure that the correct Open
MPI commands are in path?
For building Open MPI by your self with CMake, you have to configure it
in the GUI and then generate the sln files by pressing
Thanks for comment.
fixed it.
On Mon, Aug 8, 2011 at 6:28 PM, Jeff Squyres wrote:
> Mike --
>
> Does mxm_init() do Reasonable Things to check to see if the local
> OpenFabrics-capable devices are unsuitable for MXM? E.g., does it check to
> see if the local OpenFabrics devices are MXM-capable,
