[ET Trac] [Einstein Toolkit] #1769: External libraries: moving towards multiarch library directory structure

[Einstein Toolkit]

#1769: External libraries: moving towards multiarch library directory structure
------------------------------------+---------------------------------------
  Reporter:  bmundim                |       Owner:                                  
      Type:  defect                 |      Status:  review                          
  Priority:  major                  |   Milestone:  ET_2015_05                      
 Component:  EinsteinToolkit thorn  |     Version:  development version             
Resolution:                         |    Keywords:  ExternalLibraries HDF5 Multiarch
------------------------------------+---------------------------------------

Comment (by bmundim):

 Replying to [comment:9 eschnett]:
 > Adding {{{-I/usr/include}}} is most likely a bad idea, for just the
 reasons discussed earlier.

 Note that I didn't propose to add this path when we detect the external
 library, but at the end, after all external libraries have been
 configured. Also it might only be really necessary for Fortran
 compilation. There seems to have a bug in gfortran in which the system
 include paths are not searched. Take a look at this bug report thread:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707. Despite the
 documentation saying -Idir works the same as for cpp or gcc case, that's
 not true. We do need to add -Idir for system directories in Fortran if we
 hope to find system *.mod Fortran module files.

 > This shortly before a release I'd rather favour a work-around. Would
 building HDF5 yourself work? If so, then I suggest to do this for the
 release, and then we have time to discuss and test a proper fix afterwards
 that can also be backported to the release.

 Adding -I/usr/include at the end of the command line compiling Fortran
 source codes seemed to me a workaround. Yes, we can always build the
 library, but I don't want to do so and I had hoped a more general solution
 would have surfaced by now. Unfortunately it is trickier than what I
 anticipated.

 My personal workaround for Ubuntu, and Ubuntu only, is this patch together
 with commenting out the following lines of the detect.sh script:

 {{{
 HDF5_INC_DIRS="$(${CCTK_HOME}/lib/sbin/strip-incdirs.sh ${HDF5_INC_DIRS})"
 HDF5_LIB_DIRS="$(${CCTK_HOME}/lib/sbin/strip-libdirs.sh ${HDF5_LIB_DIRS})"
 }}}

 this way both system include path, /usr/include, and the library path,
 /usr/libx86_64-linux-gnu, would be searched. This works well for me
 because a) I don't plan on building any external library on ubuntu; b) I
 don't plan on using any library that is not shipped with the distribution.
 This is obviously not an workaround for everyone or on every system. Said
 that, maybe the best is to just revert these patchs on HDF5 and Boost
 external library thorns for the release. I will happily apply these
 patches on my system, everybody else builds these libraries when
 configuring their ubuntu system until we come up with a better solution.
 To me the long term solution is to identify the system include and library
 paths and add them at the end of the command line for compiling and
 linking, respectively.

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