Issue configuring libmesh with PETSc v3.17.0

[ylunalin]

Hello,

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?

[pbauman]

The solution will be to update the petsc.m4 to put -I$(PETSC_DIR) in the CPPFLAGS for the test. I can get to it this weekend if no one else fixes it before then.

[jwpeterson]

We currently check for the petscversion.h header like this:

    AC_LANG_PUSH(C)
    AC_CHECK_HEADER(${PETSC_DIR}/${PETSC_ARCH}/include/petscversion.h,
                    [enablepetsc=yes; enablepetsc_mpi=yes
                     petsc_version_h_file=${PETSC_DIR}/${PETSC_ARCH}/include/petscversion.h],
                    [
      AC_CHECK_HEADER(${PETSC_DIR}/include/petscversion.h,
                      [enablepetsc=yes; enablepetsc_mpi=yes
                       petsc_version_h_file=${PETSC_DIR}/include/petscversion.h],
                      [enablepetsc=no; enablepetsc_mpi=no])
                    ])
    AC_LANG_POP

According to the docs,

"If [4th argument to AC_CHECK_HEADER] is omitted or empty, configure will check for both header existence (with the preprocessor) and usability (with the compiler), using AC_INCLUDES_DEFAULT"

So it sounds to me that we would need to modify CFLAGS rather than preprocessor (CPPFLAGS) flags? But I'm curious what actually changed with PETSc here... I have not had a chance to download 3.17 and check it out yet.

[pbauman]

But I'm curious what actually changed with PETSc here..

It's exactly what @ylunalin said: I noticed that the culprit is the include statement #include <petscconf.h> in the file petscversion.h

The PETSc folks changed petscversion.h in 3.17.0 to start including other PETSc headers (in this case petscconf.h). Previously, even as late as 3.16.4, they did not do that.

[pbauman]

So it sounds to me that we would need to modify CFLAGS rather than preprocessor (CPPFLAGS) flags?

I believe CPPFLAGS should feed both steps, but I won't swear to it.

[jwpeterson]

OK, yeah looks like it happened in petsc/petsc@b81e3b540

We might also consider switching from AC_CHECK_HEADER to AC_TRY_COMPILE AC_COMPILE_IFELSE as some MPI implementations recommend as I don't think we really need the level of granularity (first check preprocessor, then check compilation) that AC_CHECK_HEADER provides.

[jwpeterson]

Actually we already try to compile PETSc test programs so this up-front header check should just be changed to something similar to what we have in slepc.m4 where we just test for the existence of files with test -r

            AS_IF([test -r ${SLEPC_DIR}/bmake/${PETSC_ARCH}/slepcconf],  [includefile=${SLEPC_DIR}/bmake/${PETSC_ARCH}/slepcconf],
                  [test -r ${SLEPC_DIR}/conf/slepc_common_variables],    [includefile=${SLEPC_DIR}/conf/slepc_common_variables],
                  [test -r ${SLEPC_DIR}/conf/slepc_variables],           [includefile=${SLEPC_DIR}/conf/slepc_variables],
                  [test -r ${SLEPC_DIR}/lib/slepc/conf/slepc_variables], [includefile=${SLEPC_DIR}/lib/slepc/conf/slepc_variables], dnl 3.6.0
                  [test -r ${SLEPC_DIR}/${PETSC_ARCH}/lib/slepc/conf/slepc_variables], [includefile=${SLEPC_DIR}/${PETSC_ARCH}/lib/slepc/conf/slepc_variables],
                  [AC_MSG_RESULT([<<< SLEPc configuration failed.  Could not find slepcconf/slepc_variables file. >>>])
                   enableslepc=no])

[jwpeterson]

I got an error in the configure process saying /path/to/petsc/include/petscversion.h usability ... no.

Is this the exact error message you got, or have you somehow anonymized the PATH for Discussion purposes? I'm just curious whether some strange default value was used for your PETSC_DIR environment variable.

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

Your instincts are correct, changing the PETSc header file is not a viable solution here.

[ylunalin]

Hi John,

I anonymized the PATH here. I'm confident that I correctly set the PETSC_DIR env variable. The same config/build procedure works perfectly fine with older versions of PETSC that don't include petscconf.h in petscversion.h.

Yeah, as for deleting the include statement, I knew it was a dangerous hack, and thus defer to the experts here for the proper solution :D

[boyceg]

I just ran into the same issue. What worked for me was to set CPPFLAGS="-I$PETSC_DIR/include -I$PETSC_DIR/$PETSC_ARCH/include” when configuring libMesh.

I didn't check to see if both flags were necessary, nor did I look into what changes in the PETSc headers / their organization caused this to happen.

[jwpeterson]

The fix in #3241 at least doesn't break anything for me, but I'm not using PETSc 3.17 so I won't claim that it actually fixes the problem. If anyone has a chance to try it and let us know either here or on the PR, that would be great.

[pbauman]

FYI, I'm doing a build on my laptop now and it's detecting PETSc 3.17.0 just fine now. Thanks for the fix!