dolfin team mailing list archive

[Jed Brown <fenics@xxxxxxxx>]

On 16 Mar 2008, knepley@xxxxxxxxx wrote:
> On Sun, Mar 16, 2008 at 5:18 PM, Åsmund Ødegård <aasmund@xxxxxxxxx> wrote:
> > On Sun, Mar 16, 2008 at 10:44 PM, Matthew Knepley <knepley@xxxxxxxxx> wrote:
> >  > >  This is the behavior I observed, although it was more than a year ago
> >  >  >  that I put a line in my makefile to determine if mpicxx existed in the
> >  >  >  same path, and if not, try to use the mpicc (provided by PCC_LINKER) as
> >  >  >  a C++ compiler.  I generally use openmpi, but often build PETSc
> >  >  >  with-clanguage=C since I don't use the C++ interface (I'm playing with
> >  >  >  sieve now so this has changed).  Then PCC_LINKER would give me a C
> >  >  >  compiler (mpicc) and I would look for a C++ compiler at the same path
> >  >  >  (since the code I was compiling was C++).  This worked great for me, but
> >  >  >  it broke for some people who had PETSc install mpich2.  The problem was
> >  >  >  that mpicc was actually a C++ compiler and there was no mpicxx at that
> >  >  >  path.  It would have been a PETSc configured with-clanguage=C++.  In
> >  >  >  trying to reproduce this with a recent PETSc (2.3.3-p6 and petsc-dev) it
> >  >  >  looks like mpich2 produces just mpicc (which is not a C++ compiler) when
> >  >  >  configured with-clanguage=C and correctly produces mpicxx when
> >  >  >  with-clanguage=C++.  This is entirely sane behavior.  I'm not sure why
> >  >  >  Osman is seeing the former behavior even with a recent PETSc.
> >  >
> >  >  Yes, if C++ is not turned on in PETSc, we will not generate an mpicxx when
> >  >  installing MPICH2. For the C compiler, we take whatever is specified
> >  >  using --with-cc
> >  >  or the one we find by default if nothing is specified. You can see which one we
> >  >  found using mpicc --show.
> >  >
> >
> >  This make kind of sense, of course. But it also makes it a bit hard,
> >  as Petsc tend to be quite picky about compilers. Dolfin is C++, so
> >  some mpicxx is needed when Dolfin and Petsc are linked together. Maybe
> >  the best solution is to skip the wrappers altogether, just extract
> >  what we need from mpicc -show, and build the correct commands.
> 
> I really really would not do this. It will cause future pain. I used to do that
> and gave up. The right thing to do is to actually ask for what you wany,
> --with-clanguage=c++ when building PETSc since you do in fact need C++.
> Then everything will work fine.

Dolfin does not need the C++ interface to PETSc, and packaging systems
tend not to provide the C++ version.  In my opinion, there should be a
canonical to get a C++ compiler that will work with PETSc, even when
PETSc was not built for C++, provided the MPI implementation was built
with C++ support.  Similarly, if PETSc was built --with-csupport, there
should be a canonical way to get a plain C compiler.

The following thread has our last discussion of the issue as it affected
that project.  Since I can't seem to reproduce the `mpicc links C++'
with recent patch sets, perhaps this particular issue is no longer
relevant, but it seemed to affect Osman.

https://gna.org/bugs/?9371

Jed

Attachment: pgpmbDz5HgJvT.pgp
Description: PGP signature