dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On Sun, Mar 16, 2008 at 5:50 PM, Jed Brown <fenics@xxxxxxxx> wrote:
>
> 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 problem with this approach is that it is dangerous. If you want to start
refering to things like a C++ compiler without testing it, it will
definitely break.
You might argue that we should always test it, but some people do not have
C++ compilers and further would be really mad if you tried to turn one on.
You might argue that the default should be to turn it on, rather than to leave
it off. This is mostly aesthetic I think, and we chose the opposite strategy. If
you want PETSc to check for C++ all you have to do is give one argument.
Furthermore, the C interface works just fine in this case, so you can use it if
you want.

   Matt

>  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
-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener