Opened 12 years ago
Closed 12 years ago
#308 closed defect (fixed)
Many build fails on OpenSUSE 12
Reported by: | Dave Offiler | Owned by: | Dave Offiler |
---|---|---|---|
Priority: | major | Milestone: | 6.1 |
Component: | ROPP (all) | Version: | 6.0 |
Keywords: | OpenSUSE, Beta testing, configure | Cc: |
Description
Attempted to install dependences and ROPP-6.1 on 64-bit OpenSUSE 12.2 with ifort 12.1 and gcc 4.7.1. Several issues needed to be resolved before getting a successful ropp_io build (which is as far as I got in the first beta-test session).
1) The main problem stems from this OS installing 64-bit object libraries by default to <prefix>/lib64. Since the ROPP configure script doesn't look here, it fails with missing dependency libraries (netCDF4/HDF5 in this case).
This may well apply to other OSes and/or implementations of the GNU toolset; RHEL6 may be in the majority or unique in not installing like this. We can no longer assume everything will go into <prefix>/lib
There is more than one solution (only the first tested) involving modifying the mini-scripts (potentially all *_linux ones):
- include LDFLAGS="-L$PREFIX/lib" so that this build will find prior dependencies, and add --libdir=$PREFIX/lib to the configure options, to force current library installation to /lib instead of the default /lib64
- include LDFLAGS="-L$PREFIX/lib -L$PREFIX/lib64" so that this build will find prior dependencies in either location, and let the current install be to the default /lib64
This issue applies to the HDF5, netCDF-4 and GRIB_API packages. Possibly also ZLIB, but I relied on the OS-standard libs for this. If the 2nd option is adopted, then the ROPP mini-scripts would also need at least the LDFLAGS modification.
(NB: ROPP libraries still install to <prefix>/lib as default, so a third option might be to follow the crowd and also install in /lib64, by reverse-engineering e.g. the HDF5 configure)
2) I may be wrong, but ROPP does not directly call (via Fortran) any HDF5 routines (only indirectly via the C interface of netCDF-4)? In any case, the ropp_io configure explicitly tests for the HDF5 Fortran library (I had stupidly disabled the HDF5 Fortran library build as a waste of [cpu] time and because I had a problem with the F90 when building with g95 under Cygwin).
If ROPP does indeed not call HDF5 F90, then the configure tests should be removed, allowing a faster & simpler HDF5 build.
3) HDF5 build failed with a libcurl problem. This was simply solved by installing libcurl-devel (the library was present, but by default most distros may not install the development .h files). Users may need to be warned of such dependencies (since we encourage them to use buildpack an not think for themselves!)
4) Having now built (with buildpack) hdf5, netdcf4, mobufr and grib, then ropp_utils, the ropp_io run-time tests fail. This is because the run-time shared (hdf5) libraries cannot be found - since they are in a non-standard place.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ROPP_ROOT/ifort/lib
at the terminal session command line did the trick (but see also #307) to run the tests. Clearly this is manual and compiler-specific.
It remains to be seen if this setup is still needed if the shared libraries were installed to <prefix>/lib64. I suspect it would be. How this set up could be automated would need some thought - probably some extra code in config to put this into Makefile? Even then, this wouldn't help when running the tools direct from the command line or user-scripts. May need to be done explicitly by the user.
Alternatively, HDF5 et al might be built with --disable-shared as configure options to force static-built executables (not attempted). Again this would affect potentially all the *_linux mini-scripts but would be the simplest downstream for us and for the user.
Summary: While we've got away with all of the above on RHEL6, one or more of these issues may well be a show stopper on any other OS, so we need to review whether v6.1 can be publicly released as it is now, as the build system clearly isn't fully portable. It is likely that some modifications to the mini-scripts is all that is needed, depending on the solution option(s) to be adopted.
Change history (2)
comment:1 by , 12 years ago
Owner: | set to |
---|---|
Status: | new → accepted |
comment:2 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
1) Ian has solved this problem by including both ../lib and ../lib64 in LDFLAGS in the mini-scripts.
2) The HDF5 F90 interface needs to be built to satisfy ropp_io configure. The problem building this interface was due to incorrect FFLAGS. These have now been removed from the mini-scripts, allowing the library to be build OK.
3) Users ought to be warned that HDF5 requires it's own dependencies, beyond the obvious ZLIB, and that <pkg>-devel headers are needed as well as the libraries (the latter would more than likely be pre-installed, but not always the latter).
4) --disable-shared set in mini-scripts; static builds don't need LD_LIBRARY_PATH.
Re-tested on OpenSUSE 12.2 using Ian's updated mini-scripts; now works fine for ifort (v12), g95 & gfortran. (There are still problems with sunf95, not related to this Ticket).