NCO configure does not recognize alternative UDUNITS2 library path
Command-line operators for netCDF and HDF files
Brought to you by:
zender
On my system (OpenSUSE 42.2), the library directory of several packages is PACKAGENAME/lib64 and not PACKAGENAME/lib. When I parse the udunits2 library directory via -L in the LDFLAG variable (as UDUNITS_ROOT/lib64) it is not recognized. Instead, the configure script looks in UDUNITS_ROOT/lib. The config.log file is attached.
My current workaround is to create a symbolic link pointing from UDUNITS_ROOT/lib to UDUNITS_ROOT/lib64.
Any chance you'd like to take a stab at patching configure.ac to work for OpenSUSE?
I don't have much experiance with autoconf. However, I just read a bit about this problem. As far as I understand it, there is no straightforward solution. Some systems seem to have a environment variable $CONFIG_SITE, which points to ascript which helps finding out whether we need /lib or /lib64. See e.g. https://stackoverflow.com/q/9247769/4612235 . There seem to be also different philosophies (to what extend should the configure script do the work of the user / decide for the user).
My (maybe a bit naive) suggestion would be to look for the UDUNITS libdir in three steps:
Why this order?
I think it might be reasonable to do the same for NETCDF, ANTLR, ESMF and GSL, and also for the include dir. After finding out the correct paths, they should be written into 10 variables (5 x 2 = [UDUNITS, NETCDF, ANTLR, ESMF, GSL] x [lib, include]).
What do you think about it?
This suggested approach is some kind of a brute force approach but it is the only one which I could include into the configure.ac . Although its probably not too much work, I cannot promise to do it until end of June due to some other work to be done.
Last edit: Daniel Neumann 2017-05-31
Thank you for looking into this. Only worry about UDUNITS for now. Unfortunately, even that is a bit more complex than you might realize. Look at the current handling in configure.ac. It's messy :) Probably best done by adding the SUSE-specific tests to what's already there to ensure no breakage. If you can get that to work, then it's fine to incrementally simplify things and remove cruft.
I am not sure whether it is a good idea to test whether we compile for SUSE or not. If we cross-compile for 32-bit or compile on a 32-bit system, we probably need the .../lib dir.
The variable $libdir should contain the NCO library path. If --libdir is not specified in the ,/configure call, then:
Even when --libdir was specified by the user we could assume that in most cases udunits and NCO libraries will be both installed either in .../lib or in .../lib64 library directories.
Hence I would suggest to replace the line:
by
The variables $NETCDF_LIB and $NETCDF_INC are included into the LDFLAGS and CPPFLAGS, respectively, when they exist. In addtion to the above stated changes, one might include the same procedure for $UDUNITS2_LIB and $UDUNITS2_INC as follows:
Last edit: Daniel Neumann 2017-05-31
try your suggestion on SUSE and if it works, and if you think it won't break functionality on other systems, please submit pull request on GitHub.
It works fine on SUSE and I will test it on ubuntu later on.
Last edit: Daniel Neumann 2017-06-01
I just included the first part
and testet in on OpenSUSE 42.2 and xUbuntu 16.04. There are no problems on both systems and I don't see a reasonable situation in which this approach fails.
I will try to commit it to GitHub. Never tried it before ... .
It seems that I do not have permission to submit files to the github NCO repository. Into which branch should I submit the modified files?
Daniel,
Thank you fro creating this patch. We are eager to merge it. I am not a github expert, but I think anyone with a github account can submit a pull request, because I have received and approved PRs from various people outside the project. The basic idea is you create a local branch and then create a PR of that branch against master, e.g.,
if we can't get this to work, then, with your permission, i'll just add you to the project
Ahhhh. Ok. I got it. I have to fork the NCO project first. Then it works fine. Thanks for the help.
I tested the latest NCO version available at GitHub. It configures and compiles fine.
Thanks for the patch, everything seems to work!