[petsc-dev] petsc/master: unable to link in C++ with last night PETSC_WITH_EXTERNAL_LIB variable changes

[Matthew Knepley]

On Sat, Feb 10, 2018 at 1:44 PM, Jed Brown <jed at jedbrown.org> wrote:

> Éric Chamberland <Eric.Chamberland at giref.ulaval.ca> writes:
>
> > Le 18-02-10 à 12:38, Jed Brown a écrit :
> >> Éric Chamberland <Eric.Chamberland at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180210/7c025a23/attachment.html>