[ET Trac] [Einstein Toolkit] #1769: External libraries: moving towards multiarch library directory structure
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Fri May 8 11:41:51 CDT 2015
#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 knarf):
Replying to [comment:5 bmundim]:
> Replying to [comment:4 hinder]:
> > We have other machines were Fortran support in HDF5 is disabled.
> We do need the fortran support.
The ET does not need it. That doesn't mean we shouldn't make it work, but
it lowers priority a bit.
> > 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.
Ok, then this would need to debugged.
> > In any case; if building HDF5 ourselves is the easiest solution, then
I'm happy to go with that.
We shouldn't make this the default just because some users might require
Fortran HDF5 for some of their private thorns, as long as it works
otherwise well for everybody else that is.
We could mention in the release notes that, if you are going to need HDF5
Fortran support in one of your private thorns, and you are using one of
the problematic library installations, you might be better off building
HDF5 using Cactus.
> 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.
In the long run: couldn't we find standard paths (where possible) using
something like (for C):
{{{
echo | cpp -Wp,-v 2>&1 | perl -p0e 's/.*include <...> search starts
here:.(.*)End of search list.*/\1/sm; s/(\n|^) /:/g'
}}}
In my case, that list includes
{{{
/usr/lib/gcc/x86_64-linux-gnu/4.9/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
}}}
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1769#comment:6>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list