On Sat, Feb 10, 2018 at 1:44 PM, Jed Brown <j...@jedbrown.org> wrote:
> É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). > Of course, we do have a structured dependency graph. Where is it not being used? Matt > > 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. > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
