[skip ci] internal umfpack workarounds

[juhanikataja]

This will solve the issue treated in #578

[mmuetzel]

Are we sure this doesn't cause issues on other platforms or with other compilers?
To limit the impact of potential side effects, should this be specific to the compiler with which the issue occurs? E.g., test if CMAKE_C_COMPILER_ID matches "Cray" (or "CrayClang"?) and only modify the pre-processed sources in that case?

(Maybe, also don't skip the CI to evaluate the impact at least for a few different platforms/compilers.)

[juhanikataja]

I'm pretty certain.

The issue is that the internal umfpack gets c-preprocessed with -E flag for some reason and that causes the source files to include nearly everything in libc standard headers and that will conflict with cray cc compiler when openmp offloading compilation is enabled. Apparently, the offloading pass in cray cc will cause the compiler to include some header files to source which causes the typedef conflict with __fsid_t.

Another workaround would be to disable openmp in umfpack.

Probably the best workaround, however, would be not to use -E flag in compiling umfpack and achieve the wanted effect with some other, possibly cleaner, fashion.

The [skip ci] was there because originally I didn't think this needed to be merged. And now I'm not so sure again anymore, since having a version that compiles on cray compiler without extra complications would be nice, but having a weird workaround for a somewhat weird compiler behaviour would not be nice.

[mmuetzel]

Afaict, -E tells the compiler to output the preprocessed sources.
When calling the compiler without -E, it still preprocesses the sources but proceeds to compile them after that.

I'm not entirely sure why the source files are preprocessed in a separate step in the CMake build rules. Maybe, that was before object libraries existed?

In any case, preprocessing without -fopenmp and compiling with that flag (or vice versa) could very likely cause issues. Sorting that out would probably be better than this work-around.

I'd like to attempt building the -DDINT and -DDLONG (and -DZINT and -DZLONG) versions of the source files in separate object libraries and link them to the final AMD or UMFPACK libraries.
If that doesn't work, the "next best thing" might be to add the OpenMP C flags to the preprocessor flags if necessary.

If you don't mind, I'll try to test that some time this weekend and let you know if I come up with something testable.

[mmuetzel]

I opened #587 with alternative changes (a complete overhaul of the build rules of UMFPACK and AMD) that shouldn't require compiler-specific changes.

Does that also avoid the build issue with the Cray compiler for you?