#include "lapacke.h" causes weird cinchlog compile error

[mattbement]

When I #include "lapacke.h" in my task.h file, I get the following compile error with gcc 7.3.0:
In file included from /home/bement/ristra/flecsale-mm/flecsi/flecsi/data/sparse_accessor.h:20:0, from /home/bement/ristra/flecsale-mm/specializations/flecsi-sp/utils/types.h:5, from /home/bement/ristra/flecsale-mm/apps/dsd/2d/../types.h:21, from /home/bement/ristra/flecsale-mm/apps/dsd/2d/inputs.h:13, from /home/bement/ristra/flecsale-mm/apps/dsd/2d/driver.cc:11: /home/bement/ristra/flecsale-mm/cinch/logging/cinchlog.h:1373:24: error: expected unqualified-id before ‘if’ #define clog(severity) if(true) {} else std::cerr ^ /home/bement/ristra/flecsale-mm/cinch/logging/cinchlog.h:1373:36: error: expected unqualified-id before ‘else’ #define clog(severity) if(true) {} else std::cerr

[cmsquared]

What hash of cinch are you using? That macro definition and the line number don't match the current head, and the contents of that line were changed about 8 months ago. I don't know the reason for the error, but it might be worth trying to update to the latest hash to see if you can compile, and if so, update flecsale-mm.

[mattbement]

It looks like there are at least 3 versions of cinch in flecsale: The one directly in the flecsale-mm checkout, as well as ones in flecsi and ristra. The ones in flecsale-mm and flecsi are 912d041, but the one in ristra is 19b181a. Not sure if this is by design or if it even matters.

[cmsquared]

For the most part, it shouldn't matter. Except when it does :). A lot of our projects are like this, but I've still never seen your error message. The top-level one is the one that matters.

[charest]

This offending line seems to be

#define clog(severity) if(true) {} else std::cerr

But I cannot see how this macro is failing, unless there is a name collision. How is lapacke.h included in driver? Can you post/email a snippet?

[cmsquared]

One thing to note is that lapacke.h defines a lot of things within extern "c" block, using the __cplusplus compiler macro. I'm not saying this is the cause, but there is an explicit check that adds another } to close the extern block, based on this macro. Make sure you are using g++ and not gcc somehow...