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