Commit r5034 to the flesh breaks many external libraries

[Erik Schnetter]

Commit r5034 modified the options that are passed to external libraries. I see build failures on machines using the Intel compiler. Reverting this commit seems to cure the problem. Frank Löffler and I are investigating.

Keyword:

[Frank Löffler]

This is actually a mistake in several option lists. They define

CPP_OPENMP_FLAGS = -openmp

The Intel compiler isn't at fault here. It only occurs for Intel compilers, since only intel compiler option lists use, e.g., C_OPENMP_FLAGS = -openmp, and because of that (I guess) people also used it for CPP_OPENMP_FLAGS.

However, there is no option for OpenMP for cpp. This is actually interpreted as -oFILENAME where any output is put into a file called 'penmp', which throws autoconf off because it is looking for this output and configures libraries wrong.

What gcc optionlists do (and we should do for intel as well, as we typically use the gnu cpp) is to use

CPP_OPENMP_FLAGS = -fopenmp

This option is understood by cpp (and passed down to subprocesses if there are any).

Thus, I propose to change entries in simfactory option lists that include the first, wrong version for CPP_OPENMP_FLAGS to use -fopenmp. This change works for me - GSL (for example) builds with the patch.

Commit r5034 had an influence, because before we overwrote all kinds of autoconf-tests of the different libraries, which we shouldn't - and Cactus' autoconf-test didn't use CPP_OPENMP_FLAGS for the autoconf-tests (which might be an issue of its own - I believe it should).

[Erik Schnetter]

We pass CPPFLAGS to the C compiler, not to cpp. For example, when determining dependencies for C and C++, we use CPPFLAGS, but we do not use CFLAGS nor CXXFLAGS since we don't compile. In this case, we still need the compiler's OpenMP flag to ensure that the #ifdef _OPENMP and the #include <omp.h> are handled correctly. Thus, we need to continue to pass -openmp for CPP_OPENMP_FLAGS.

I believe this is a case where Cactus uses a flag differently from the way it is used elsewhere. A similar flag is LIBS, which we need to unset in all configure.sh scripts: Cactus does not prepend the "-l" flag to the libraries there, but every other code expects this, so passing LIBS would lead to errors. Of course, we don't want to use the libraries against Cactus will be linked when building an external library anyway, so this is fine.

I also just see that icc and icpc accept both -openmp and -fopenmp. We should simply switch to -fopenmp to circumvent this problem for now.

[Frank Löffler]

We probably shouldn't use CPPFLAGS to pass to the C or C++ compiler, but the corresponding CFLAGS ect. Is there a reason we shouldn't do that? The CFLAGS for instance shouldn't (do they?) contain the actual action (like compiling). Shouldn't they work just as well, or better?

Also, can I assume your last comment means 'reviewed ok'?

[Erik Schnetter]

When Cactus determines include dependencies, it does so by calling the compiler with certain flags. It does not call cpp directly, since this may lead to different include files -- e.g. GNU's cpp would now know what Intel-specific files icc would include. cpp needs to be called via icc, so that icc can add its -I flags.

CPPFLAGS contains the flags necessary for this preprocessing. These are mostly the -I and -D flags. CFLAGS contains only the flags necessary for compiling, e.g. -Wall or -xHost or -O2.

It seems that other libraries (e.g. GSL) interpret CPPFLAGS differently, and/or call GNU cpp even if the compiler is Intel icc.

We should use CPPFLAGS to pass the -I and -D flags. If we did not do this, and if we used CFLAGS instead, then we would need to pass CFLAGS when looking for dependencies, which could lead to warnings about unused flags.

[Erik Schnetter]

To be explicit: No, we should not change all -openmp to -fopenmp. As I described, Cactus passes these to icc, and we can only make this change if the respective version of icc understands the flags -fopenmp. Modern versions of icc do, but I am not sure about older versions. This needs to be tested on each system before committing.

[Frank Löffler]

Agreed.