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

[Éric Chamberland]

oh my god, if

-lpetsc -lmpi

works for me you make my day!!! :) really!

I will try it for sure!!!
I tried to maintain a very long linking line since sooo many years, if I 
can get ride of it, I will be happy!

Thanks,

Eric


Le 18-02-10 à 13:44, Jed Brown a écrit :
> É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.