[Einstein Toolkit] #100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ------------------------------------+--------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: ExternalLibraries HDF5 | ------------------------------------+--------------------------------------- When the user sets for example both
HDF5=yes HDF5_DIR=/usr
the script HDF5.sh fails to assert if all library files are currently present in the user HDF5 implementation, what leads later on to a linking error, halting then the executable building process. Some library files are missing in the HDF5 version shipped by the Ubuntu distro, for example:
libhdf5_hl_cpp.a
Shouldn't the script output an warning message, and allow linking without this option, since this is not a core library file?
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: ExternalLibraries HDF5 ----------------------+----------------------------------------------------- Changes (by knarf):
* component: Other => Cactus
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: Cactus | Version: Resolution: fixed | Keywords: ExternalLibraries HDF5 ----------------------+----------------------------------------------------- Changes (by eschnett):
* status: new => closed * resolution: => fixed
Comment:
ExternalLibraries/HDF5 now checks for all libraries.
Not all thorns that use HDF5 require all libraries; however, these dependencies are difficult to catch. The current approach is to provide C, C++, and Fortran bindings, because there are thorns that use these. We could conceivably use a more differentiated approach in the future, e.g. with different thorns HDF5, HDF5_Fortran, HDF5_CXX etc.
Bruno, I notice that Ubuntu often splits software into a set of packages. Is there another package you could install next to hdf5-dev to get lighdf5_hl_cpp.a? If not, you can just set HDF5_DIR=BUILD, and this thorn will build HDF5 by itself. This will take a bit of time, but neatly circumvents all installation trouble.
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: Cactus | Version: Resolution: fixed | Keywords: ExternalLibraries HDF5 ----------------------+-----------------------------------------------------
Comment (by bmundim):
Hi Erik,
I still think that the hdf5.sh script is flawed. I set HDF5_DIR=BUILD and the script still finds the Ubuntu implementation and skips building the library. I truly think that when HDF5_DIR=BUILD is set it should build and link against the ET shipped library, not the system one (Note that other tools out of Cactus code may need to use the system one, at least out of convenience since it is installed in a standard directory). At the end, if I am sure the system library provides support for fortran and C++, all I need to do is to comment out the ExternalLibraries/HDF5 from the thorn list.
Regarding the HDF5 shipped with Ubuntu: it doesn't provide support for C++ or fortran. So it is important that the BUILD option really builds and links against the library shipped with ET. This should be the default.
Anyway, this is my opinion. What do you think? Thanks, Bruno.
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: ExternalLibraries HDF5 ----------------------+----------------------------------------------------- Changes (by knarf):
* status: closed => reopened * resolution: fixed =>
Comment:
Can you please attache the build log where it tries to find/build the library and uses the Ubuntu version? If I read the current script correctly, if should a) not search for another library because HDF5_DIR is set (e.g. you should _not_ see "HDF5 selected, but HDF5_DIR not set. Checking some places..."), and b) it should print "Building HDF5...".
Now, I could imagine later problems with ordering in the linker line ect., and that could be seen most easily from the log.
I reopen the ticket for now because there still seem to be problems.
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: ExternalLibraries HDF5 ----------------------+-----------------------------------------------------
Comment (by bmundim):
Hi Frank,
I am not sure which log you are referring to, so I attached what I could find relevant.
Thanks, Bruno.
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: ExternalLibraries HDF5 ----------------------+-----------------------------------------------------
Comment (by bmundim):
Ok,
I had already set on my .cshrc the HDF5_DIR to /usr. I set it like this in order to build a visualisation tool, hdf5todv, a long time ago. I thought this env variable would be overwritten (at least it should) by the Cactus options. Maybe it is, but the hdf5.sh script checks first if it is already set. It should have a work around this. The user env variables outside the .cactus/config option file should not interfere with Cactus or external libraries build.
Cheers, Bruno.
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: ExternalLibraries HDF5 ----------------------+-----------------------------------------------------
Comment (by eschnett):
Cactus explicitly chooses environment variables over configuration options that have been specified in an options file. This was probably done because Cactus is built with a "make" command, which allows you to set environment variables on the make command line. Allowing the environment to override options in a configuration file means that you can do the following:
make sim options=optionsfile VARIABLE=OVERRIDE
and thus override the setting for VARIABLE that may exist in "optionsfile".
We may want to change this (and I think we should); however, there is unfortunately nothing we can do specifically for HDF5_DIR to override this.
#100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: Cactus | Version: Resolution: invalid | Keywords: ExternalLibraries HDF5 ----------------------+----------------------------------------------------- Changes (by hinder):
* status: reopened => closed * resolution: => invalid
Comment:
I have created #332 requesting that Cactus not override configuration options with variables from the user's environment, and am closing the present ticket.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit