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. Probably have to sleep on this :) Åsmund _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
