v2.0.0 installation fails on macOS

[milanmlft]

I get the following error when trying to install nloptr 2.0.0 from source (both on R 4.1.2 and R-devel):

** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for 'nloptr' in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/Users/milan/Library/R/x86_64/4.1/library/00LOCK-nloptr/00new/nloptr/libs/nloptr.so':
  dlopen(/Users/milan/Library/R/x86_64/4.1/library/00LOCK-nloptr/00new/nloptr/libs/nloptr.so, 6): Library not loaded: @rpath/libnlopt.0.dylib
  Referenced from: /Users/milan/Library/R/x86_64/4.1/library/00LOCK-nloptr/00new/nloptr/libs/nloptr.so
  Reason: image not found
Error: loading failed

You can find the full output in attachment: nloptr.txt

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value                       
#>  version  R version 4.1.2 (2021-11-01)
#>  os       macOS Big Sur 10.16         
#>  system   x86_64, darwin17.0          
#>  ui       X11                         
#>  language (EN)                        
#>  collate  en_US.UTF-8                 
#>  ctype    en_US.UTF-8                 
#>  tz       Europe/Brussels             
#>  date     2022-02-02                  
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date       lib source           
#>  backports     1.3.0   2021-10-27 [1] CRAN (R 4.1.1)   
#>  cli           3.1.0   2021-10-27 [1] CRAN (R 4.1.1)   
#>  crayon        1.4.1   2021-02-08 [1] CRAN (R 4.1.0)   
#>  digest        0.6.28  2021-09-23 [1] CRAN (R 4.1.0)   
#>  ellipsis      0.3.2   2021-04-29 [1] standard (@0.3.2)
#>  evaluate      0.14    2019-05-28 [1] CRAN (R 4.1.0)   
#>  fansi         0.5.0   2021-05-25 [1] CRAN (R 4.1.0)   
#>  fastmap       1.1.0   2021-01-25 [1] CRAN (R 4.1.0)   
#>  fs            1.5.0   2020-07-31 [1] CRAN (R 4.1.0)   
#>  glue          1.4.2   2020-08-27 [1] CRAN (R 4.1.0)   
#>  highr         0.9     2021-04-16 [1] CRAN (R 4.1.0)   
#>  htmltools     0.5.2   2021-08-25 [1] CRAN (R 4.1.0)   
#>  knitr         1.36    2021-09-29 [1] CRAN (R 4.1.0)   
#>  lifecycle     1.0.1   2021-09-24 [1] CRAN (R 4.1.0)   
#>  magrittr      2.0.1   2020-11-17 [1] CRAN (R 4.1.0)   
#>  pillar        1.6.4   2021-10-18 [1] CRAN (R 4.1.0)   
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.1.0)   
#>  purrr         0.3.4   2020-04-17 [1] CRAN (R 4.1.0)   
#>  R.cache       0.15.0  2021-04-30 [1] CRAN (R 4.1.0)   
#>  R.methodsS3   1.8.1   2020-08-26 [1] CRAN (R 4.1.0)   
#>  R.oo          1.24.0  2020-08-26 [1] CRAN (R 4.1.0)   
#>  R.utils       2.11.0  2021-09-26 [1] CRAN (R 4.1.0)   
#>  reprex        2.0.1   2021-08-05 [1] CRAN (R 4.1.0)   
#>  rlang         0.4.12  2021-10-18 [1] CRAN (R 4.1.0)   
#>  rmarkdown     2.11    2021-09-14 [1] CRAN (R 4.1.0)   
#>  rstudioapi    0.13    2020-11-12 [1] CRAN (R 4.1.0)   
#>  sessioninfo   1.1.1   2018-11-05 [1] CRAN (R 4.1.0)   
#>  stringi       1.7.5   2021-10-04 [1] CRAN (R 4.1.0)   
#>  stringr       1.4.0   2019-02-10 [1] CRAN (R 4.1.0)   
#>  styler        1.6.2   2021-09-23 [1] CRAN (R 4.1.0)   
#>  tibble        3.1.5   2021-09-30 [1] CRAN (R 4.1.0)   
#>  utf8          1.2.2   2021-07-24 [1] CRAN (R 4.1.0)   
#>  vctrs         0.3.8   2021-04-29 [1] standard (@0.3.8)
#>  withr         2.4.2   2021-04-18 [1] CRAN (R 4.1.0)   
#>  xfun          0.27    2021-10-18 [1] CRAN (R 4.1.0)   
#>  yaml          2.2.1   2020-02-01 [1] CRAN (R 4.1.0)   
#> 
#> [1] /Users/milan/Library/R/x86_64/4.1/library
#> [2] /Library/Frameworks/R.framework/Versions/4.1/Resources/library

[astamm]

Thanks for reporting that. Might it be possible that you have a file ~/.Rprofile or a file ~/.Renviron? If you have such a file or files, can you copy their content please?

[astamm]

Also, it seems you already have nlopt as a system build but of version < 2.7.0. This triggers a cmake build of v2.7.1 and I suspect with all your includes and linking libraries that the compiler might have to choose between both versions and might be a bit lost. If that were to be the case, we should definitely improve upon this situation. In the meantime, I think that if you either upgrade or delete your older version of nlopt, then you should be able to install nloptr successfully.
Alternatively, it might be an issue with the files I mentioned above.

[milanmlft]

Thanks for the help!

Thanks for reporting that. Might it be possible that you have a file ~/.Rprofile or a file ~/.Renviron? If you have such a file or files, can you copy their content please?

I checked and I don't see anything that could interfere with the installation. The problem also occurred when running the installation through Rscript --vanilla.

However, removing my previous nlopt installation did the trick! So it seems that there was indeed some confusion between the different versions.

[astamm]

We might need to dig into this. @eddelbuettel: is the current strategy in configure.ac supposed to avoid this or is there something we missed?

[eddelbuettel]

We made a decision to fail when the version is too low:

nloptr/configure.ac

Lines 54 to 63 in 69bfb77

	## And if we have pkg-config, use it to test minimal version
	if test x"${have_pkg_config}" != x"no"; then
	AC_MSG_CHECKING([for pkg-config checking NLopt version])
	if pkg-config --atleast-version=2.7.0 nlopt; then
	AC_MSG_RESULT([>= 2.7.0])
	need_to_build="no"
	else
	AC_MSG_RESULT([insufficient: NLopt 2.7.0 or later is preferred.])
	fi
	fi

We then still force a build. Turns out that those can turn sour. Maybe that can be improved by reordering -I and -L flags to point to 'our' rather than system nlopt. I don't know -- you are the one who thinks we should always build :)

[astamm]

Actually, I think the issue comes from here:

nloptr/configure.ac

Lines 38 to 52 in 69bfb77

	AC_PATH_PROG(have_pkg_config, pkg-config, no)
	## If yes, also check for whether pkg-config knows nlopt
	if test x"${have_pkg_config}" != x"no"; then
	AC_MSG_CHECKING([if pkg-config knows NLopt])
	if pkg-config --exists nlopt; then
	AC_MSG_RESULT([yes])
	nlopt_include=$(pkg-config --cflags nlopt)
	nlopt_libs=$(pkg-config --libs nlopt)
	AC_SUBST([NLOPT_INCLUDE], "${nlopt_include}")
	AC_SUBST([NLOPT_LIBS], "${nlopt_libs}")
	else
	AC_MSG_RESULT([no])
	have_pkg_config="no"
	fi
	fi

It seems we update PKG_CPPFLAGS and PKG_LIBS variables regardless of whether the system nlopt is recent enough.
I think moving the if statement which tests minimal version within the if statement that tests whether nlopt already exists should do the trick.

[astamm]

Something like that should do the trick:

## But: Can we use pkg-config?
AC_PATH_PROG(have_pkg_config, pkg-config, no)
## If yes, also check for whether pkg-config knows nlopt
if test x"${have_pkg_config}" != x"no"; then
    AC_MSG_CHECKING([if pkg-config knows NLopt])
    if pkg-config --exists nlopt; then
        AC_MSG_RESULT([yes])
        ## Since nlopt has been found, test for minimal version requirement
        AC_MSG_CHECKING([for pkg-config checking NLopt version])
        if pkg-config --atleast-version=2.7.0 nlopt; then
            AC_MSG_RESULT([>= 2.7.0])
            nlopt_include=$(pkg-config --cflags nlopt)
            nlopt_libs=$(pkg-config --libs nlopt)
            AC_SUBST([NLOPT_INCLUDE], "${nlopt_include}")
            AC_SUBST([NLOPT_LIBS],    "${nlopt_libs}")
            need_to_build="no"
        else
            AC_MSG_RESULT([insufficient: NLopt 2.7.0 or later is preferred.])
        fi
    else
        AC_MSG_RESULT([no])
        have_pkg_config="no"
    fi
fi

[eddelbuettel]

(Next time, could you make it easier and show a diff?)

Is the change you are proposing the inner else? Whichmessages but does not error, so inexperienced users may again be lost in front of too much output if it fails later?

PS And I missed that you were posting two tickets at once. Yes -- the propagation of what was found may be related, that is a good catch as we didn't really consider that case.

PPS Yep, agree. Combining tests for 'does it exist and is it new enough' should help!

[astamm]

We might also remove the setting of have_pkg_config="no" in the else part of the outer if statement since this variable is then not used anymore.
Yes, I'll show a diff next time, sorry.

[eddelbuettel]

Agreed on the have_pkg_config="no", that was just to hop into the next block and all that did not account for crossover effects.