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