Menu

#96 NCO configure does not recognize alternative UDUNITS2 library path

None
closed-fixed
5
2017-06-06
2017-05-30
No

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.

1 Attachments

Discussion

  • Charlie Zender

    Charlie Zender - 2017-05-30

    Any chance you'd like to take a stab at patching configure.ac to work for OpenSUSE?

     
  • Daniel Neumann

    Daniel Neumann - 2017-05-30

    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:

    • Is UDUNITS2_LIB set? If yes, use it.
    • Else have a look if ${UDUNITS2_PATH}/lib exists. If yes, use it.
    • Else have a look if ${UDUNITS2_PATH}/lib64 exists. If yes, use it.
    • Else error

    Why this order?

    • The lib and include dirs of udunits might have a different prefix. If this is the case the user would set the UDUNITS2_LIB and UDUNITS2_INCLUDE (or UDUNITS2_INC).
    • If we are on a multi-arch system, the .../lib might host the 32-bit libraries and .../lib64 the 64-bit libraries. Therefore, it is reasonable to look into lib64 first.

    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
    • Charlie Zender

      Charlie Zender - 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.

       
  • Daniel Neumann

    Daniel Neumann - 2017-05-31

    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:

    • it is set to ${exec_prefix}/lib64 on my SUSE system (via a script to which $CONFIG_SITE points)
    • it is set to ${exec_prefix}/lib on my Ubuntu system.

    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:

    LDFLAGS="${LDFLAGS} -L${UDUNITS2_PATH}/lib"
    

    by

    if test -d "${UDUNITS2_PATH}/`basename $libdir`"; then
      LDFLAGS="${LDFLAGS} -L${UDUNITS2_PATH}/`basename $libdir`"
    else
      LDFLAGS="${LDFLAGS} -L${UDUNITS2_PATH}/lib"
    fi
    

    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:

    if test "${UDUNITS2_LIB}"; then
        if test -d "${UDUNITS2_LIB}"; then
        LDFLAGS="-L${UDUNITS2_LIB} ${LDFLAGS} "
        else
        echo "WARNING: UDUNITS2_LIB location \"${UDUNITS2_LIB}\" does not exist!"
        fi
    fi # !UDUNITS2_LIB
    if test "${UDUNITS2_INC}"; then
        if test -d "${UDUNITS2_INC}"; then
        CPPFLAGS="-I${UDUNITS2_INC} ${CPPFLAGS} "
        else
        echo "WARNING: UDUNITS2_INC location \"${UDUNITS2_INC}\" does not exist!"
        fi
    fi # !UDUNITS2_INC
    
     

    Last edit: Daniel Neumann 2017-05-31
  • Charlie Zender

    Charlie Zender - 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.

     
  • Daniel Neumann

    Daniel Neumann - 2017-06-01

    It works fine on SUSE and I will test it on ubuntu later on.

     

    Last edit: Daniel Neumann 2017-06-01
  • Daniel Neumann

    Daniel Neumann - 2017-06-03

    I just included the first part

    if test -d "${UDUNITS2_PATH}/`basename $libdir`"; then
      LDFLAGS="${LDFLAGS} -L${UDUNITS2_PATH}/`basename $libdir`"
    else
      LDFLAGS="${LDFLAGS} -L${UDUNITS2_PATH}/lib"
    fi
    

    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 ... .

     
  • Daniel Neumann

    Daniel Neumann - 2017-06-03

    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?

     
    • Charlie Zender

      Charlie Zender - 2017-06-05

      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.,

      git checkout -b newfeature
      # Make local changes
      git commit -am 'foo'
      # Push local changes
      git push origin newfeature
      git push -u origin newfeature
      # Delete local branch once it is merged upstream
      git branch -d newfeature
      

      if we can't get this to work, then, with your permission, i'll just add you to the project

       
      • Daniel Neumann

        Daniel Neumann - 2017-06-06

        Ahhhh. Ok. I got it. I have to fork the NCO project first. Then it works fine. Thanks for the help.

         
  • Daniel Neumann

    Daniel Neumann - 2017-06-06

    I tested the latest NCO version available at GitHub. It configures and compiles fine.

     
  • Charlie Zender

    Charlie Zender - 2017-06-06
    • status: open --> closed-fixed
    • assigned_to: Charlie Zender
    • Group: -->
     
  • Charlie Zender

    Charlie Zender - 2017-06-06

    Thanks for the patch, everything seems to work!

     

Log in to post a comment.

MongoDB Logo MongoDB