- changed status to open
- removed comment
Cactus shouldn't mess with some flags after they have been setup.
Currently Cactus sets up flags like CPPFLAGS or CFLAGS by adding e.g. CPP_OPENMP_FLAGS. However, later it overwrites these again by their original value in sbin/ProcessConfiguration.pl (search for FIXME).
The attached patch implements what the 'FIXME' suggests - accepting the drawbacks that are mentioned there: that configuration settings not originating from a thorn might not be forwarded from e.g., a .cactus/config file. MPI was one of these, but this is now handled differently anyway. With this patch, we would need to be aware of these and might need to add them to @allowed_opts in the future.
Without the patch however, compilation might fail for perfectly valid setups. One of these is when using openmp, setting all the corresponding _OPENMP_FLAGS, but not setting CPPFLAGS (only CPP_OPENMP_FLAGS). In this case ProcessConfiguration.pl will set CFLAGS to the version in the config file (without the -openmp), but it will leave CPPFLAGS to the version with* -openmp. This later leads to a linker error in external libraries, since compilation there uses CPPFLAGS (with openmp), but the linker doesn't (It correctly uses CFLAGS, but this doesn't have openmp flags here).
Keyword:
Comments (13)
-
reporter -
- removed comment
Where is @allowed_opts set?
-
reporter - removed comment
It's populated by what thorns define (in ProcessConfiguration.pl).
-
reporter - removed comment
This also breaks building 'curl'.
-
- removed comment
Curl is building fine for me, as do all other thorns in ExternalLibraries. What are your setting and symptoms?
-
reporter - removed comment
Same as above. A build fails when using openmp, set using C_OPENMP_FLAGS (and corresponding), but not defining CPPFLAGS. For the release we can use a workaround to define CPPFLAGS (as empty), but this should be cleaned up later.
-
reporter - removed comment
ping?
-
- removed comment
I never used a global .config file. So if that is the only thing that possibly breaks. Fine with me.
-
reporter - removed comment
It's the only thing I am aware of. Now (just after a release) is probably the best time to get it into the development version I would think. Ok to apply?
-
- removed comment
please apply.
-
- changed status to open
- removed comment
-
reporter - changed status to resolved
- removed comment
Applied as r5034.
-
- edited description
- changed status to closed
- Log in to comment
To be applied after the spring release.