[ET Trac] [Einstein Toolkit] #1006: ExternalLibraries' configure.sh scripts handle /usr inconistently

[Einstein Toolkit]

#1006: ExternalLibraries' configure.sh scripts handle /usr inconistently
------------------------------------+---------------------------------------
  Reporter:  rhaas                  |       Owner:                   
      Type:  defect                 |      Status:  new              
  Priority:  minor                  |   Milestone:                   
 Component:  EinsteinToolkit thorn  |     Version:                   
Resolution:                         |    Keywords:  ExternalLibraries
------------------------------------+---------------------------------------

Comment (by rhaas):

 Replying to [comment:1 eschnett]:
 > The -L path should not contain those libraries that are searched by
 default. The reason is that otherwise these system locations are
 potentially searched first, making it impossible to replace libraries that
 already exist on the system. That is, if we want to provide a library via
 ExternalLibraries (e.g. HDF5) that already exists on the system, the
 linker may then choose the system library instead, which would be wrong.
 >
 > /opt/local etc. (the "Mac OS X equivalents") are not part of the default
 search path, and should not be excluded.
 >
 > /usr/include and /usr/local/include should be excluded from -I (include
 path).

 This fails on OSX using homebrew where gcc does not by default look in
 /usr/local/XXX. So it does not find even the homebrew-installed hdf5
 libraries unless one explicitly adds -L/usr/local/lib to the paths. The
 current gcc man page states:
 {{{
        -Idir
            Add the directory dir to the head of the list of directories to
 be searched for header
            files.  This can be used to override a system header file,
 substituting your own version,
            since these directories are searched before the system header
 file directories.  However,
            you should not use this option to add directories that contain
 vendor-supplied system
            header files (use -isystem for that).  If you use more than one
 -I option, the directories
            are scanned in left-to-right order; the standard system
 directories come after.

            If a standard system include directory, or a directory
 specified with -isystem, is also
            specified with -I, the -I option is ignored.  The directory is
 still searched but as a
            system directory at its normal position in the system include
 chain.  This is to ensure
            that GCC's procedure to fix buggy system headers and the
 ordering for the "include_next"
            directive are not inadvertently changed.  If you really need to
 change the search order
            for system directories, use the -nostdinc and/or -isystem
 options.
 }}}
 so removing the "standard" directories from -I is not required for gcc
 (but may be for other compilers). Not having to remove them ourselves
 would avoid putting information about the compiler behaviour into the
 configuration scripts for external libraries.

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