[ET Trac] [Einstein Toolkit] #1406: Commit r5034 to the flesh breaks many external libraries

[Einstein Toolkit]

#1406: Commit r5034 to the flesh breaks many external libraries
-------------------------+--------------------------------------------------
  Reporter:  eschnett    |       Owner:  knarf@…            
      Type:  defect      |      Status:  review             
  Priority:  critical    |   Milestone:  ET_2013_11         
 Component:  SimFactory  |     Version:  development version
Resolution:              |    Keywords:                     
-------------------------+--------------------------------------------------
Changes (by knarf):

  * priority:  blocker => critical
  * status:  new => review
  * component:  Cactus => SimFactory
  * milestone:  => ET_2013_11


Comment:

 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).

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1406#comment:1>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit