[R-pkg-devel] MacOS flat namespace
Fabio Corradini Santander
|@b|o@corr@d|n| @end|ng |rom |n|@@c|
Fri May 8 11:07:15 CEST 2020
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
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.
El jue., 7 may. 2020 a las 17:23, David Winsemius (<dwinsemius using comcast.net>)
> On 5/7/20 7:37 AM, Fabio Corradini Santander wrote:
> 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
> 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
> 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:
> You might want to post the question on the R-sig-mac mailing list if you
> remain stuck.
> Thanks once again,
[[alternative HTML version deleted]]
More information about the R-package-devel