v2.0.0 installation fails on macOS
milanmlft opened this issue · comments
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
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?
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.
Thanks for the help!
Thanks for reporting that. Might it be possible that you have a file
~/.Rprofileor 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.
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?
We made a decision to fail when the version is too low:
Lines 54 to 63 in 69bfb77
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 :)
Actually, I think the issue comes from here:
Lines 38 to 52 in 69bfb77
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.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
(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!
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.
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.