It pretty much depends on the PETSc install.  If PETSc is configured using --with-mpi-dir or something similar then libMesh will pick that up from the petscconf file.  If PETSc is configured to use mpicc etc... directly, then
libMesh can't snoop PETSc's MPI config, and you better just use mpicxx etc...  for libMesh.

And F77 comes in indirectly...  We need to be able to link to Fortran libraries, which means autoconf needs to figure out what libraries are needed to link with Fortran-compiled objects with a C main function.  This requires access to the Fortran compiler.

The real issue is that the user needs to be sure to build libMesh with the same MPI PETSc (& in the future Trilinos) used.  To be safe, the same compiler too.  I've had problems in the past with a gcc libMesh on top of an intel-compiled PETSc.  (Note that both gcc and intel-compiler libMesh worked on top of a gcc-compiled PETSc.)


From: on behalf of Derek Gaston
Sent: Mon 4/28/2008 8:08 PM
To: Roy Stogner
Subject: Re: [Libmesh-devel] Compilation / run / mpi problems

Why is this an issue though?  I've never specified --with-cxx or
--with-cc with libMesh before... and never had a problem because I
specify MPI_HOME correctly...

Also... around Sandia we don't use mpicc or mpicxx... as they are
sometimes buggy (especially on certain supercomputers with very
specific mpi setups)... we prefer to interrogate the mpi setup and add
the library and include paths ourselves...

Is there something I'm missing?  I guess I just prefer to call g++ directly...


On Mon, Apr 28, 2008 at 3:22 PM, Roy Stogner <> wrote:
>  On Mon, 28 Apr 2008, Martin Lüthi wrote:
> > Thanks for your answers. While I could not figure out what was wrong
> > (I got no more information in debug mode), using PETSc 2.3.3-12 works
> > smoothly. The crucial thing seems to be the usage of the mpi
> > compilers.
> >
> >
> > >  ./configure --with-cxx=mpicxx --with-cc=mpicc --with-f77=mpif77
> > >
> >
> > Should that be documented on the "Install" page?
> >
>  Actually, it probably ought to be fixed in our ./configure scripts.
>  We shouldn't be forcing users to specify mpi compiler scripts
>  manually, but we're using the default AC_PROG_CC and AC_PROG_CXX
>  macros to search for compilers, and (without arguments) those don't
>  search for mpicc or mpicxx.  I don't even see where we're getting the
>  --with-f77 option; some other macro must be calling AC_PROG_F77 I
>  suppose.
>  Does anyone more familiar than I am with autoconf want to take a look
>  at this?  Using something like:
>  AC_PROG_CC([mpicc gcc cc])
>  (along with equivalent CXX, F77 lines) looks like a quick fix, but
>  we'd have to move around some tests, I think, since we'd rather not
>  test for mpicc unless MPI is enabled.
>  It'll be a while before I can get to this myself; my source tree is
>  currently a bit out of sync due to ParallelMesh code changes, and I'd
>  rather not futz with something else before I get around to finishing
>  and merging those.
>  ---
>  Roy
> -------------------------------------------------------------------------
>  This email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
> _______________________________________________
>  Libmesh-devel mailing list

This email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.;198757673;13503038;p?
Libmesh-devel mailing list