> You can't mix stdio.h (which I think g++ uses internally) with > MPICH2's C++ bindings, because for some reason the MPI-2 C++ binding > reuses macro names from the C standard. We used to have a workaround > for this in libMesh, but it caused its own problems, so since we only > use the MPI C bindings anyway we now only link against MPICH with C++ > bindings turned off.
Yeah -- Unfortunately, the MPI C++ interface is really not very useful. It puts everything in an MPI namespace, but that is about it. Besides, we use PETSc/Parmetis,both of which require MPI_*** in the global namespace anyway. I prefer using the C API wrapped as it is in Parallel:: anyway - I think Roy's use of templates and function overloading here is much more useful than the C++ MPI interface. Also, since the C++ ABI is not entirely standard, using the C++ MPI ivterface would likely further limit the choice of compilers when using e.g. Vendor-supplied MPI on supercomputers. > Because ICES keeps f77 around linked to g77 from gcc 3.2, the libMesh > configure script tries to link using library paths from the old > version of gcc; this confuses the linker when called from g++: > "warning: libstdc++.so.6, needed by > /ices/roystgnr/software/libmesh/lib/x86_64-unknown-linux-gnu_dbg/libmesh.so, > may conflict with libstdc++.so.5" Telling configure to use the newer > gfortran instead fixed this. > > I'd say the f77/gfortran confusion counts as a bug in our configure > scripts, but I'm not sure what we could do to fix it other than detect > and error out when we saw such a version conflict. Hopefully we won't > have too many people trying to install on systems where the default C > compiler is GCC4 and the default Fortran compiler is GCC3. This one is a little touchy and has been an issue for a while... The crux of the problem is that we check for 'AC_PROG_F77' which checks for a Fortran-77 capable compiler. Since PETSc only requires Fortran-77 support this is the right thing to do, since libMesh only needs to be capable of linking to f77 programs. ./configure searches for a number of compilers in this case, and it looks for g77 before gfortran. Again, this is the right thing to do. 'AC_PROG_FC' is one solution, but this looks for a Fortran-90+ compiler which we really don't need. Since this is pretty gcc/g77 specific, we should be able to detect a gcc/g77 version mismatch, look for gfortran, and then abort if unsuccessful. -Ben ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
