If libmesh configure fails with new version of PETSc (v3.17.x), try an older version instead

[Y. Luna Lin]

Hello all,

In the last week or so, I tried to configure and build libmesh with --enable-petsc-required, with a recent version of PETSc (v3.17.0).
I got an error in the configure process saying /path/to/petsc/include/petscversion.h usability ... no.
The usability check here is to check for successful compilation of a simple program with this header file, so if this failed the usability is no.
After some digging, I noticed that the culprit is the include statement #include <petscconf.h> in the file petscversion.h.
If I simple delete this include state, the configure script runs normally and PETSc is included as an optional package. However, I don't know the inner workings of PETSc or libmesh well, deleting an include statement seems to be a dangerous move.

By chance, I also found that in older versions of PETSc, this include statement doesn't exist. So in the end I just went with an older version (v.3.13.x) instead.

Has anyone else encountered this issue before? If so, did you find a work around? I have posted this also to the libmesh github discussion, and can update the answers here if there's any.

[Boyce Griffith]

On Apr 20, 2022, at 7:09 AM, Y. Luna Lin <y.li...@gmail.com> wrote:

Hello all,

In the last week or so, I tried to configure and build libmesh with --enable-petsc-required, with a recent version of PETSc (v3.17.0).
I got an error in the configure process saying /path/to/petsc/include/petscversion.h usability ... no.
The usability check here is to check for successful compilation of a simple program with this header file, so if this failed the usability is no.
After some digging, I noticed that the culprit is the include statement #include <petscconf.h> in the file petscversion.h.
If I simple delete this include state, the configure script runs normally and PETSc is included as an optional package. However, I don't know the inner workings of PETSc or libmesh well, deleting an include statement seems to be a dangerous move.

By chance, I also found that in older versions of PETSc, this include statement doesn't exist. So in the end I just went with an older version (v.3.13.x) instead.

I just encountered this issue yesterday. A workaround that I found was to specify the PETSc include directories to the C/C++ preprocessor by setting:

CPPFLAGS="-I$PETSC_DIR/include -I$PETSC_DIR/$PETSC_ARCH/include”

when configuring libMesh.

Incidentally, I also ran into a problem with the current libMesh master using C++17 features even though I was setting my C++ compiler flags to use the C++14 standard. Unfortunately, the ancient version of SAMRAI that we use needs to be patched further to work if the C++17 standard is enabled. The most recent release of libMesh (which appears to be 1.6.2) doesn’t have this problem.

[Yiming Gan]

I second that adding this line solves the issue in my case: CPPFLAGS="-I$PETSC_DIR/include -I$PETSC_DIR/$PETSC_ARCH/include"