On 22 January 2009 at 15:23, Jeff Squyres wrote: | (note that Chrisophe is not subscribed to devel, so if he replies, we | won't see it -- sorry; spammers force this kind of policy on us :-( )
(Yes, I also own a few mailing lists for the R Project and use the same policy. He is CC'ed though.) | On Jan 22, 2009, at 6:10 AM, Dirk Eddelbuettel wrote: | | > This bug report just came in against the new Open MPI 1.3 release | > which we | > built the same way as 1.2.*. | > | > Christophe, | > | > Sorry about that. And yes, it should be a drop-in replacement. You | > can | > revert back to 1.2.8 from testing for now. If you have a small | > self-contained C++ example, it would help debugging. | | FWIW, "drop in replacement" in this context means recompile and | relink. We did not provide binary compatibility between the 1.2 | series and the 1.3 series. Ack. So we need to push that through all Open MPI-using apps in Debian. | More below. | | > | I just upgraded to openmpi 1.3-1. The compilation of my codes went | > fine. | > | The linking stage sometimes failed with | > | | > | undefined reference to `MPI::Win::Set_errhandler(MPI::Errhandler | > const&)' | > | undefined reference to `MPI::Comm::Set_errhandler(MPI::Errhandler | > const&)' | > | | > | in some external libs (trilinos) using openmpi | > | | > | When linking is ok, runtime fails with for example | > | | > | symbol lookup error: /usr/lib/libHYPRE_FEI.so.2.0.0: undefined | > symbol: | > | _ZN3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE | > | | > | After playing with nm I got | > | | > | nm /usr/lib/openmpi/lib/libmpi_cxx.a | > | 00000000 W _ZN3MPI6Status9Set_errorEi | > | 00000000 W _ZNK3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZNK3MPI4Comm14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZN3MPI6Status9Set_errorEi | > | 00000000 W _ZNK3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZNK3MPI4Comm14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZN3MPI6Status9Set_errorEi | > | 00000000 W _ZNK3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZNK3MPI4Comm14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZN3MPI6Status9Set_errorEi | > | 00000000 W _ZNK3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZNK3MPI4Comm14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZN3MPI6Status9Set_errorEi | > | 00000000 W _ZNK3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZNK3MPI4Comm14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZN3MPI6Status9Set_errorEi | > | 00000000 W _ZNK3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE | > | 00000000 W _ZNK3MPI4Comm14Set_errhandlerERKNS_10ErrhandlerE | > | | > | which mean that the missing symbol is registered as a weak symbol. | > | | > | PS: I have -lmpi++ -lmpi at the linking stage and libmpi_cxx.* are | > present in | > | /usr/lib/openmpi/lib | | I'm not sure what -lmpi++ is for -- that's not an OMPI library, at | least not from the v1.2 or v1.3 series (I'd have to check versions | before that; I don't remember offhand). It's a Debianism. Similar to use providing several 'vi' or 'emacs' implementation we also try (tried...) to align LAM, MPICH, OpenMPI,... This means we still provide symlinks from orterun to mpirun etc pp and here: edd@ron:~$ ls -l /usr/lib/libmpi++.so /etc/alternatives/libmpi++.so lrwxrwxrwx 1 root root 34 2009-01-21 10:53 /etc/alternatives/libmpi++.so -> /usr/lib/openmpi/lib/libmpi_cxx.so lrwxrwxrwx 1 root root 29 2008-01-20 19:42 /usr/lib/libmpi++.so -> /etc/alternatives/libmpi++.so edd@ron:~$ | Is there a reason you're not using the mpiCC wrapper compiler to | compile/link MPI C++ codes? | | If you prefer to call the compiler directly, you might want to use | "mpiCC --showme:compile" to get the compiler flags and "mpiCC -- | showme:link" to get the linker flags. I say this because OMPI | reserves the right to change what compiler and linker flags are | required from release to release. Using the --showme:<foo> option | gives you a forward-compatible way to keep compiling and linking if | you choose not to use the OMPI wrapper compilers. | | Here's the help output from v1.3 showing all the --showme options: | | -------------------------------------------------------------------------- | mpiCC [-showme[:<command,compile,link,incdirs, | libdirs,libs,version>]] args | | -showme:command Show command used to invoke real compiler | -showme:compile Show flags added when compiling | -showme:link Show flags added when linking | -showme:incdirs Show list of include dirs added when compiling | -showme:libdirs Show list of library dirs added when linking | -showme:libs Show list of libraries added when linking | -showme:version Show version of Open MPI | -------------------------------------------------------------------------- | | (both -showme and --showme work) Ack. That also worked for me. What I find confusing is that $ mpiCC -showme:link -o helloMPIworld helloMPIworld.cpp -pthread -o helloMPIworld helloMPIworld.cpp -L/usr/lib/openmpi/lib -lmpi_cxx -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl but I also got by manually with just $ g++ -o helloMPIworld helloMPIworld.cpp -I/usr/lib/openmpi/include -L/usr/lib/openmpi/lib -lmpi_cxx -lmpi i.e. way fewer libraries. And for what it is worth, Rmpi still segfaults on MPI_Init() for me :-/ But Christophe, could you try mpiCC ? Dirk -- Three out of two people have difficulties with fractions.
