[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