#1769: External libraries: moving towards multiarch library directory structure ------------------------------------+--------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: reopened Priority: major | Milestone: ET_2016_05 Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ExternalLibraries HDF5 Multiarch ------------------------------------+--------------------------------------- Changes (by knarf):
* milestone: ET_2015_11 => ET_2016_05
Comment:
Replying to [comment:27 bmundim]:
the issue with using 'gcc --dumpmachine' is that we end up having a
system directory in the middle of a list of directories in the linking stage. Then it could pick up other system libraries we might not want to use. As long as the system libraries are linked last then it should be ok. The same for the include directories. As long as the system include directories are last in the list then we are fine.
This is not handled, true. We'll leave this for after the release now. The code stripping the paths would need to know about this (lib/sbin/strip- libdirs.sh) - and that code is not new, so that code wouldn't have stripped this in the old version as well.
Anyways, I am reopening this ticket because the script is not able to
find /usr/include/hdf5.mod which is in my system and hdf5 library installed does support fortran.
Assuming this is Ubuntu (trusty, and for reference): no pkg-config {{{ /use/include/hdf5.h /usr/include/hdf5.mod /usr/lib/x86_64-linux-gnu/libhdf5.so }}}
The script (on my Ubuntu VM) finds hdf5.h and libhdf5.so. It never checks for hdf5.mod (only for the relevant libraries). It does search for the include path, and finds it as /usr/include. Because that is a system include path, it does not get added to the INC_DIRS, for the reason you stated. It goes on marking the library as found and starts to compile. It never fails since there is no Fortran HDF5 code in the ET.
Now, gfortran decided to not search standard include paths when looking for .mod files (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707). This means, to get things to compile, you would have to add -I/usr/include - which obviously is a bad idea in general. That's why distributions started to put these into separate directories, which is the only sensible way - but doesn't help us here now. We cannot add /usr/include in INC_DIRS in case Fortran is requested, because that might just break the next library. We also do not sort the list of library/include directories according to their 'is system path' status for each compiler command. We probably could dabble into that mess - but is that what you want? One possible easier way would be to detect such situation, and to copy the .mod file to somewhere inside Cactus, and reference that path. This would separate the mod file from the system include path. But this would require checking that this file is always up2date with it's original location. We could use a symlink to make sure this is true, but would still need to check for it dangling.
In any case - I would like to see this issue with Fortran module files and standard include paths be rather in a new ticket, or things get too confusing here.
In addition your solution was applied only for HDF5 external library.
There are others that need to be patched such as Boost, PAPI and pthreads. They were also moved to multiarch layout on ubuntu.
Indeed. We didn't want to change all this for all libraries so short before a release. Eventually all libraries should use the flesh scripts.