Compile error in Blackbear

dschwen commented 5 months ago

These BLAS/Lapack forward declarations conflict with declaration we pull in through PETSc: https://github.com/Argonne-National-Laboratory/neml/blob/65c2ee4bbfb4f5499f17952e64ed87f85a1ef538/include/math/nemlmath.h#L17-L29

See compile error here: https://civet.inl.gov/job/2140682/

Compiling C++ (in opt mode) /data/civet0/build/blackbear/moose/framework/build/unity_src/distributions_Unity.C...
In file included from /data/civet0/build/blackbear/contrib/neml/include/math/rotations.h:5,
                 from /data/civet0/build/blackbear/contrib/neml/include/elasticity.h:7,
                 from /data/civet0/build/blackbear/contrib/neml/include/models.h:5,
                 from /data/civet0/build/blackbear/contrib/neml/include/parse.h:5,
                 from /data/civet0/build/blackbear/moose/framework/src/utils/InputParameters.C:24,
                 from /data/civet0/build/blackbear/moose/framework/build/unity_src/utils_Unity.C:28:
/data/civet0/build/blackbear/contrib/neml/include/math/nemlmath.h:19:8: error: conflicting declaration of C function 'void dgetrf_(const int&, const int&, double*, const int&, int*, int&)'
   19 |   void dgetrf_(const int & m, const int & n, double* A, const int & lda, int* ipiv, int & info);
      |        ^~~~~~~
In file included from /opt/petsc/include/petscblaslapack.h:72,
                 from /data/civet0/build/blackbear/moose/framework/src/utils/ColumnMajorMatrix.C:19,
                 from /data/civet0/build/blackbear/moose/framework/build/unity_src/utils_Unity.C:9:
/opt/petsc/include/petscblaslapack_mangle.h:53:47: note: previous declaration 'void dgetrf_(const PetscBLASInt*, const PetscBLASInt*, PetscReal*, const PetscBLASInt*, PetscBLASInt*, PetscBLASInt*)'

Ping @bwspenc

bwspenc commented 5 months ago

This must be something that just cropped up, right? What changed?

reverendbedford commented 5 months ago

This just happened to me in deer as well. I don’t know what changed. I’m fine changing my definitions but I guess a better solution would be to do something more consistent than a hard coded function signature.

On Wed, Mar 27, 2024 at 15:05 Ben Spencer @.***> wrote:

This must be something that just cropped up, right? What changed?

— Reply to this email directly, view it on GitHub https://github.com/Argonne-National-Laboratory/neml/issues/170#issuecomment-2023751716, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZISQY3DFGDOD2QT3W6DB3Y2MKA3AVCNFSM6AAAAABFLO56SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTG42TCNZRGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

bwspenc commented 4 months ago

It turns out that this was due to a MOOSE change that added a #include "parse.h" to pull in the framework/contrib/hit/parse.h file, which has the same name as neml/include/parse.h. That was fixed yesterday, and blackbear builds again.

Argonne-National-Laboratory / neml

Compile error in Blackbear #170