dolfin team mailing list archive

[Jed Brown <fenics@xxxxxxxx>]

On 16 Mar 2008, aasmund@xxxxxxxxx wrote:

> On Sun, Mar 16, 2008 at 6:20 PM, Jed Brown <fenics@xxxxxxxx> wrote:
> >
> > On 16 Mar 2008, aasmund@xxxxxxxxx wrote:
> >
> >  > On Sun, Mar 16, 2008 at 4:18 PM, osman <osman@xxxxxxxx> wrote:
> >  >
> >  > Somehow, Petsc is reporting a C compiler (mpicc) that we are not able
> >  > to find a c++ version of. Now, this should really be taken care of
> >  > more gracefully, by just skipping Petsc as a dependency (and an error
> >  > message)
> >
> >  When you have PETSc download mpich2, my recollection is that it only has
> >  the binary mpicc, even if it is really a C++ compiler.  This has caused
> >  some confusion for another project I'm involved in.
> 
> That doesn't sounds completely correct. At least the mpich I have that
> petsc downloaded and installed, have both mpicxx, mpif77, and more.
> What do you mean with "mpicc, even if it is really a C++ compiler"? Do
> you mean that it use the correct backend (e.g. g++) based on the file
> you feed it with? If so, do you have any suggestion on a suitable test
> such that I can build that into the logic?

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.

Jed

Attachment: pgp3qpxvLZ_ZG.pgp
Description: PGP signature