> 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. Matt -- 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
