Éric Chamberland <eric.chamberl...@giref.ulaval.ca> writes: > Le 18-02-10 à 12:38, Jed Brown a écrit : >> Éric Chamberland <eric.chamberl...@giref.ulaval.ca> writes: >> >>> >>> and into this block there was the "-lmpi_cxx" that we need... >> The point is that if you are linking C++ code that calls the MPI C++ >> interface, then *you* should link with mpicxx or equivalent. > The funny thing, is that we are hopefully *not* using the C++ API of > MPI. We do use the C API since MPI 1.0. > Then, I am asking myself why this link error shows up now...since > nothing calls it... hmmm, let me dig into this...
Is StatistiqueMemoire not your code? | /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/GIREF/obj/dev/StatistiqueMemoire.o: | In function `MPI::Op::Init(void (*)(void const*, void*, int, | MPI::Datatype const&), bool)': | /opt/openmpi-1.10.2/include/openmpi/ompi/mpi/cxx/op_inln.h:122: undefined reference to `ompi_mpi_cxx_op_intercept' | /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/GIREF/obj/dev/StatistiqueMemoire.o: | In function `MPI::Intracomm::Create_graph(int, int const*, int const*, | bool) const': | /opt/openmpi-1.10.2/include/openmpi/ompi/mpi/cxx/intracomm.h:25: undefined reference to `MPI::Comm::Comm()' | /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/GIREF/obj/dev/StatistiqueMemoire.o: | In function `MPI::Intercomm::Merge(bool) const': | /opt/openmpi-1.10.2/include/openmpi/ompi/mpi/cxx/intracomm_inln.h:23: undefined reference to `MPI::Comm::Comm()' | /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/GIREF/obj/dev/StatistiqueMemoire.o: | In function `MPI::Intracomm::Split(int, int) const': | /opt/openmpi-1.10.2/include/openmpi/ompi/mpi/cxx/intracomm_inln.h:23: undefined reference to `MPI::Comm::Comm()' | /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/GIREF/obj/dev/StatistiqueMemoire.o: | In function `MPI::Intracomm::Create(MPI::Group const&) const': | /opt/openmpi-1.10.2/include/openmpi/ompi/mpi/cxx/intracomm_inln.h:23: undefined reference to `MPI::Comm::Comm()' | /pmi/cmpbib/compilation_BIB_gcc_redhat_petsc-master_debug/COMPILE_AUTO/GIREF/obj/dev/StatistiqueMemoire.o: | In function `MPI::Intracomm::Clone() const': >> You should not depend on PETSc to provide anything but PETSc to your >> application (so if you call other libraries that your configuration of >> PETSc uses, you should take responsibility to link them explicitly; this > Wait: you mean for example if I configure MUMPS (or not) with PETSc, I > have to build my link line with all MUMPS dependencies or not myself? Do you call MUMPS directly or through the PETSc interface? Think about this from the perspective of packaging with shared libraries, where we ask what needs to be updated when interfaces change. Suppose we have these interface dependencies: libpetsc : libmumps libmpi app : libpetsc libmpi Since MUMPS makes no guarantee of binary compatibility between releases, updating MUMPS 5.1.2 to 5.1.3 requires rebuilding everything that link to it. Since PETSc calls MUMPS directly, libpetsc must be rebuilt. If your App does not call MUMPS directly, then you should link it with -lpetsc -lmpi Now your binaries continue to work after libpetsc has been updated to link the newer libmumps. If you needlessly linked libmumps without calling it directly, then you would also need to rebuild your App. That is called overlinking and is prohibited by most packaging guidelines because it wastes lots of time and bandwidth for maintainers and users. If you use pkg-config with PETSc, you get only -lpetsc when linking with shared libraries. (Pkg-config will give you everything for static linking because it is needed and the concept of overlinking doesn't exist in the same sense, though removing excess from the link line is still desirable to make it easier to read and faster to link.) Note that PETSc's own dependency management is messy because someone in the early days of BuildSystem thought that concatenating strings was sufficient, instead of maintaining a structured dependency graph to be topologically sorted at the final stage (pkg-config does this). > I wanted to be "lazy" and to use the same line *you* are using for > passing libs (and in the good *order* which is not easy to manage)... as > I can rely on this line to link "pure" petsc examples... ;) >> is important when using shared libraries). But you should definitely >> not depend on PETSc to provide your application with stuff that has been >> REMOVED from MPI (more than five years ago) and that PETSc does not use. > I agree, this C++ MPI API is not a very good excuse to add boring work > into any software configuration and maintenance.