#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:4 hinder]:
Does this only affect Fortran?
Apparently yes, but I am not confident we avoid problems for other thorns completely. If I set HDF5_DIR to /usr in my option list and the detect.sh script finds out the library is at /usr/lib/TARGET, where TARGET is the host architecture like x86_64-linux-gnu for example, it sets HDF5_LIB_DIRS to that directory. The potential problem is that other libraries might be there as well and we might not want them. Maybe the solution to the problem I am facing is adding the /usr/lib/TARGET to the system default library search directory list.
We have other machines were Fortran support in HDF5 is disabled.
We do need the fortran support.
Nothing in the ET requires it, and we only decided to require it because
it was "easy" and wouldn't cause any problems (#1158). Or maybe Cactus will make use of (broken) Fortran support if it finds it, even if it is told not to require it?
In this case we tell cactus we need fortran support, the library does support fortran, but Cactus doesn't find the fortran modules offered by the library in standard places such as /usr/include/hdf5.mod. I am not sure why.
In any case; if building HDF5 ourselves is the easiest solution, then
I'm happy to go with that.
At least for the release it might be safer to not introduce this TARGET library path when detecting and configuring cactus. If we add it to the default system search directories then it might solve this problem. I am not sure where this is hard coded on flesh though.