Re: [R-pkg-devel] MacOS flat namespace
Can you provide a bit more context? I just grabbed the pkg source from CRAN and it builds fine. $ clang --version Apple clang version 11.0.3 (clang-1103.0.32.59) Target: x86_64-apple-darwin19.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin ─ Session info ─── setting value version R version 4.0.0 RC (2020-04-21 r78267) os macOS Catalina 10.15.5 system x86_64, darwin17.0 ui RStudio language (EN) collate en_US.UTF-8 ctypeen_US.UTF-8 tz America/New_York date 2020-05-06 ─ Packages ─── package * version date lib source assertthat0.2.12019-03-21 [1] CRAN (R 4.0.0) backports 1.1.62020-04-05 [1] CRAN (R 4.0.0) bit * 1.1-15.2 2020-02-10 [1] CRAN (R 4.0.0) bit64 * 0.9-72017-05-08 [1] CRAN (R 4.0.0) callr 3.4.32020-03-28 [1] CRAN (R 4.0.0) cli 2.0.22020-02-28 [1] CRAN (R 4.0.0) codetools 0.2-16 2018-12-24 [1] CRAN (R 4.0.0) crayon1.3.42017-09-16 [1] CRAN (R 4.0.0) desc 1.2.02018-05-01 [1] CRAN (R 4.0.0) devtools* 2.2.22020-02-17 [1] CRAN (R 4.0.0) digest0.6.25 2020-02-23 [1] CRAN (R 4.0.0) ellipsis 0.3.02019-09-20 [1] CRAN (R 4.0.0) fansi 0.4.12020-01-08 [1] CRAN (R 4.0.0) fs1.4.12020-04-04 [1] CRAN (R 4.0.0) glue 1.4.02020-04-03 [1] CRAN (R 4.0.0) lattice 0.20-41 2020-04-02 [1] CRAN (R 4.0.0) magrittr 1.5 2014-11-22 [1] CRAN (R 4.0.0) memoise 1.1.02017-04-21 [1] CRAN (R 4.0.0) pkgbuild 1.0.62019-10-09 [1] CRAN (R 4.0.0) pkgload 1.0.22018-10-29 [1] CRAN (R 4.0.0) prettyunits 1.1.12020-01-24 [1] CRAN (R 4.0.0) processx 3.4.22020-02-09 [1] CRAN (R 4.0.0) ps1.3.22020-02-13 [1] CRAN (R 4.0.0) R62.4.12019-11-12 [1] CRAN (R 4.0.0) raster3.1-52020-04-19 [1] CRAN (R 4.0.0) Rcpp 1.0.4.6 2020-04-09 [1] CRAN (R 4.0.0) remotes 2.1.12020-02-15 [1] CRAN (R 4.0.0) rgdal 1.4-82019-11-27 [1] CRAN (R 4.0.0) rlang 0.4.52020-03-01 [1] CRAN (R 4.0.0) rprojroot 1.3-22018-01-03 [1] CRAN (R 4.0.0) rstudioapi0.11 2020-02-07 [1] CRAN (R 4.0.0) sessioninfo 1.1.12018-11-05 [1] CRAN (R 4.0.0) sp1.4-12020-02-28 [1] CRAN (R 4.0.0) testthat 2.3.22020-03-02 [1] CRAN (R 4.0.0) uFTIR * 0.1.12020-03-11 [1] CRAN (R 4.0.0) usethis * 1.5.12019-07-04 [1] CRAN (R 4.0.0) withr 2.2.02020-04-20 [1] CRAN (R 4.0.0) [1] /Library/Frameworks/R.framework/Versions/4.0/Resources/library > On May 6, 2020, at 06:17, Fabio Corradini Santander > wrote: > > Hi, > Two months ago I released a package I developed in Debian 9 GCC ( > https://CRAN.R-project.org/package=uFTIR). The package was accepted on > CRAN, and it can be installed on Windows and Linux machines. However, it is > not working on MacOS. I don't know why. The problem starts after the > installation, as the OS cannot load the compiled code. Cutting the long > paths of CRAN, the problem looks like (for r-oldrel-osx-x86_64): > > ... > ** testing if installed package can be loaded from temporary location > Error: package or namespace load failed for ‘uFTIR’ in dyn.load(file, > DLLpath = DLLpath, ...): > unable to load shared object '.../libs/uFTIR.so': > dlopen(.../libs/uFTIR.so, 6): Symbol not found: > _H5P_CLS_DATASET_CREATE_ID_g > Referenced from: .../libs/uFTIR.so > Expected in: flat namespace > in .../libs/uFTIR.so > Error: loading failed > ... > (The missing symbol for r-release-osx-x86_64 is a different > one: _jpeg_resync_to_restart) > > I saw this thread (https://github.com/RcppCore/RcppArmadillo/issues/224) > about Rcpp, but CRAN is not using gcc, but clang, so it is not really the > same... although I was lost when they discussed about libc++ and libstdc++. > > I also saw this thread from stackoverflow ( > https://stackoverflow.com/questions/40922814/error-in-dyn-loaddllfile-unable-to-load-shared-object-expected-in-flat-na) > but I don't have a mix between cpp and plain c. > > I think that probably has to do with my Makevars file ( > https://community.rstudio.com/t/error-during-the-installation-of-utf8-package/4005/2)... > maybe I shouldn't use PKG_LIBS and LDLIBS instead? But if I change it, how > will it affect the -already successful- installations on windows and linux? > > The Makevars for Mac and Linux is: > > CXX_STD = CXX11 > PKG_CXXFLAGS =
Re: [R-pkg-devel] MacOS flat namespace
Hi, [SOLVED] It was a problem of linking the libraries correctly, as suggested by Rodrigo Tobar and David Winsemius. I checked the package in rhub and it was working fine in the macos-highsierra-release platform, which uses homebrew to install gdal and proj. These are probably the settings that Bob Rudis used and that's why he didn't catch the problem. However, the package check did not work ok in the macos-highsierra-release-cran platform, probably because CRAN uses KingChaos distribution of GDAL, etc. As I wasn't sure, I opened an issue in the rhub github page (#372) and Gábor Csárdi pointed me in the right direction. I saw how rgdal solved its system requirements. I copied their configure.ac file and targeted my exports to generate an ad-hoc configure file and ta-dah! it's working ok in both r-hub platforms (and hopefully it will on cran too). Now I need to prune rgdal configure.ac file to remove all that it isn't necessary. Thank you, Fabio. El jue., 7 may. 2020 a las 17:23, David Winsemius () escribió: > > On 5/7/20 7:37 AM, Fabio Corradini Santander wrote: > > Hi, > Thank you both very much for your help. Summarizing your comments: > 1. There were no problems when installing the package from CRAN on a macOS > Catalina with clang11 and R 4.0.0. > 2. Since I don't use any of the objects directly, it is probably a gdal > thing due to an improper(?) installation. > > OK, but the problem happens on CRAN during the CRAN checks for the OS X and > macOS system flavors... Does this mean that there might be something wrong > with CRAN gdal installation for OS X and macOS? (I don't think so, plus how > can I check that without bothering CRAN maintainers?) > > > Make sure you have a proper gdal installation; after that things should > work. If you want you could be more defensive about this, and add some > logic to your configure script to test if a binary compiled against gdal > runs correctly or not, and react accordingly (e.g., if gdal is a strong > dependency then you don't continue further into the compilation of your > package). > > Although Rodrigo suggestion will work, if I abort the installation I will > fail the CRAN check, which is the reason I'm asking this question... > > You might want to look at the 'sf' package to see how it handles GDAL > SystemRequirements. > > When I was using MacOS a few years ago I would typically need to make GDAL > available on my system using the KingChaos distribution of the GDAL, GEOS, > PROJ bundle whenever there was a major change in macOS. It provides a > proper framework installation. > > If the user has chosen (against the Mac fork's maintainer's advice) to > install GDAL and friends using homebrew, there may be difficulty during the > linkage steps trying to find the headers that will not be in the expected > directory. If they have gone the homebrew route, then I believe there are > additional steps needed to establish the proper system environment symlinks > and/or environment variables. You can probably find some discussion in the > R-sig-mac mailing list archives. I generally use the MarkMail search > facility. You can try: > > > https://markmail.org/search/?q=+list%3Aorg.r-project.r-sig-mac+gdal > > > You might want to post the question on the R-sig-mac mailing list if you > remain stuck. > > -- > > David. > > Thanks once again, > > Fabio. > > > -- [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] MacOS flat namespace
On 5/7/20 7:37 AM, Fabio Corradini Santander wrote: > Hi, > Thank you both very much for your help. Summarizing your comments: > 1. There were no problems when installing the package from CRAN on a macOS > Catalina with clang11 and R 4.0.0. > 2. Since I don't use any of the objects directly, it is probably a gdal > thing due to an improper(?) installation. > > OK, but the problem happens on CRAN during the CRAN checks for the OS X and > macOS system flavors... Does this mean that there might be something wrong > with CRAN gdal installation for OS X and macOS? (I don't think so, plus how > can I check that without bothering CRAN maintainers?) > >> Make sure you have a proper gdal installation; after that things should >> work. If you want you could be more defensive about this, and add some >> logic to your configure script to test if a binary compiled against gdal >> runs correctly or not, and react accordingly (e.g., if gdal is a strong >> dependency then you don't continue further into the compilation of your >> package). > Although Rodrigo suggestion will work, if I abort the installation I will > fail the CRAN check, which is the reason I'm asking this question... You might want to look at the 'sf' package to see how it handles GDAL SystemRequirements. When I was using MacOS a few years ago I would typically need to make GDAL available on my system using the KingChaos distribution of the GDAL, GEOS, PROJ bundle whenever there was a major change in macOS. It provides a proper framework installation. If the user has chosen (against the Mac fork's maintainer's advice) to install GDAL and friends using homebrew, there may be difficulty during the linkage steps trying to find the headers that will not be in the expected directory. If they have gone the homebrew route, then I believe there are additional steps needed to establish the proper system environment symlinks and/or environment variables. You can probably find some discussion in the R-sig-mac mailing list archives. I generally use the MarkMail search facility. You can try: https://markmail.org/search/?q=+list%3Aorg.r-project.r-sig-mac+gdal You might want to post the question on the R-sig-mac mailing list if you remain stuck. -- David. > > Thanks once again, > > Fabio. > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] MacOS flat namespace
Hi, Thank you both very much for your help. Summarizing your comments: 1. There were no problems when installing the package from CRAN on a macOS Catalina with clang11 and R 4.0.0. 2. Since I don't use any of the objects directly, it is probably a gdal thing due to an improper(?) installation. OK, but the problem happens on CRAN during the CRAN checks for the OS X and macOS system flavors... Does this mean that there might be something wrong with CRAN gdal installation for OS X and macOS? (I don't think so, plus how can I check that without bothering CRAN maintainers?) > Make sure you have a proper gdal installation; after that things should > work. If you want you could be more defensive about this, and add some > logic to your configure script to test if a binary compiled against gdal > runs correctly or not, and react accordingly (e.g., if gdal is a strong > dependency then you don't continue further into the compilation of your > package). Although Rodrigo suggestion will work, if I abort the installation I will fail the CRAN check, which is the reason I'm asking this question... Thanks once again, Fabio. -- [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] MacOS flat namespace
Hi, On 6/5/20 6:17 pm, Fabio Corradini Santander wrote: ... Cutting the long paths of CRAN, the problem looks like (for r-oldrel-osx-x86_64): ... ** testing if installed package can be loaded from temporary location Error: package or namespace load failed for ‘uFTIR’ in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '.../libs/uFTIR.so': dlopen(.../libs/uFTIR.so, 6): Symbol not found: _H5P_CLS_DATASET_CREATE_ID_g Referenced from: .../libs/uFTIR.so Expected in: flat namespace in .../libs/uFTIR.so Error: loading failed _H5P_CLS_DATASET_CREATE_ID_g comes from the HDF5 library. You don't seem to use it directly, and is probably a transitive dependency coming from gdal, which you do link against, so it seems more like a problem with gdal, not with your code. You could double check this by trying to compile anything else against that gdal installation and see if it works, or the fact that you are compiling an R package. You will find many people on internet having exactly the same problem but in other products, not R. It seems to boil down to a mismatch in how hdf5 was compiled, and how hdf5 users (in this case, gdal) compile against the library (with/without defining the H5_BUILT_AS_DYNAMIC_LIB preprocessor macro). But again, this is probably on gdal's side, not yours. Make sure you have a proper gdal installation; after that things should work. If you want you could be more defensive about this, and add some logic to your configure script to test if a binary compiled against gdal runs correctly or not, and react accordingly (e.g., if gdal is a strong dependency then you don't continue further into the compilation of your package). (The missing symbol for r-release-osx-x86_64 is a different one: _jpeg_resync_to_restart) No idea, but I'd suspect gdal here again, not your code. Cheers, Rodrigo __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
