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

[Jed Brown]

É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).

> 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.