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

[Éric Chamberland]

oh my, looks like "-lpetsc -lmpi" works for us!!!

(sounds of head banging on desk)

;)

thanks!!!

Eric



Le 18-02-10 à 15:29, Éric Chamberland a écrit :
> 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.