On 16 Mar 2008, [EMAIL PROTECTED] wrote: > On Sun, Mar 16, 2008 at 5:18 PM, Åsmund Ødegård <[EMAIL PROTECTED]> wrote: > > On Sun, Mar 16, 2008 at 10:44 PM, Matthew Knepley <[EMAIL PROTECTED]> 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
pgprdrTs3Bug7.pgp
Description: PGP signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
