How to fix "configure: error: libproj not found in standard or given locations." when installing {{sf}} on macOS?

Hi everyone :slightly_smiling_face:

I'm trying to install sf 0.9-0 on my Mac (running macOS Catalina 10.15.4) and I haven't been able to due to a configuration error. Seems like I'm missing a file (?) called libproj...

After running `install.package("sf") I get a prompt asking if I want to install the package from source, I said yes and I got the following output:

installing the source package โ€˜sfโ€™

trying URL 'https://cran.rstudio.com/src/contrib/sf_0.9-0.tar.gz'
Content type 'application/x-gzip' length 8474738 bytes (8.1 MB)
==================================================
downloaded 8.1 MB

* installing *source* package โ€˜sfโ€™ ...
** package โ€˜sfโ€™ successfully unpacked and MD5 sums checked
** using staged installation
configure: CC: clang
configure: CXX: clang++ -std=gnu++11
checking for gdal-config... /usr/local/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 2.4.4
checking GDAL version >= 2.0.1... yes
checking for gcc... clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ISO C89... none needed
checking how to run the C preprocessor... clang -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking gdal.h usability... yes
checking gdal.h presence... yes
checking for gdal.h... yes
checking GDAL: linking with --libs only... yes
checking GDAL: /usr/local/Cellar/gdal/2.4.4_2/share/gdal/pcs.csv readable... yes
checking GDAL: checking whether PROJ is available for linking:... yes
checking GDAL: checking whether PROJ is available fur running:... yes
configure: GDAL: 2.4.4
checking proj.h usability... yes
checking proj.h presence... yes
checking for proj.h... yes
checking PROJ: checking whether PROJ and sqlite3 are available for linking:... no
configure: error: libproj not found in standard or given locations.
ERROR: configuration failed for package โ€˜sfโ€™
* removing โ€˜/Library/Frameworks/R.framework/Versions/3.6/Resources/library/sfโ€™
* restoring previous โ€˜/Library/Frameworks/R.framework/Versions/3.6/Resources/library/sfโ€™

I also tried installing it using devtools::install_github("r-spatial/sf") without success. I think the outputs are the same but here it is in case I overlooked something:

Downloading GitHub repo r-spatial/sf@master
โœ“  checking for file โ€˜/private/var/folders/qp/11_9l8590y79g2ck741t5dx00000gq/T/RtmpfhBVcC/remotes15c2199afdc7/r-spatial-sf-8cc2adf/DESCRIPTIONโ€™ (367ms)
โ”€  preparing โ€˜sfโ€™:
โœ“  checking DESCRIPTION meta-information ...
โ”€  cleaning src
โ”€  running โ€˜cleanupโ€™
โ”€  checking for LF line-endings in source and make files and shell scripts (498ms)
โ”€  checking for empty or unneeded directories
โ”€  building โ€˜sf_0.9-1.tar.gzโ€™
   
* installing *source* package โ€˜sfโ€™ ...
** using staged installation
configure: CC: clang
configure: CXX: clang++ -std=gnu++11
checking for gdal-config... /usr/local/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 2.4.4
checking GDAL version >= 2.0.1... yes
checking for gcc... clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ISO C89... none needed
checking how to run the C preprocessor... clang -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking gdal.h usability... yes
checking gdal.h presence... yes
checking for gdal.h... yes
checking GDAL: linking with --libs only... yes
checking GDAL: /usr/local/Cellar/gdal/2.4.4_2/share/gdal/pcs.csv readable... yes
checking GDAL: checking whether PROJ is available for linking:... yes
checking GDAL: checking whether PROJ is available fur running:... yes
configure: GDAL: 2.4.4
checking proj.h usability... yes
checking proj.h presence... yes
checking for proj.h... yes
checking PROJ: checking whether PROJ and sqlite3 are available for linking:... no
configure: error: libproj not found in standard or given locations.
ERROR: configuration failed for package โ€˜sfโ€™
* removing โ€˜/Library/Frameworks/R.framework/Versions/3.6/Resources/library/sfโ€™
* restoring previous โ€˜/Library/Frameworks/R.framework/Versions/3.6/Resources/library/sfโ€™
Error: Failed to install 'sf' from GitHub:
  (converted from warning) installation of package โ€˜/var/folders/qp/11_9l8590y79g2ck741t5dx00000gq/T//RtmpfhBVcC/file15c2502038fa/sf_0.9-1.tar.gzโ€™ had non-zero exit status

This happens even after following the instructions from sf's GitHub repo (e.g., install pkg-config and gdal through homebrew), which should make it possible to install sf from source so I have no idea where I went wrong...

Does anybody know how to solve this?

Here's my session info:

R version 3.6.3 (2020-02-29)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Catalina 10.15.4

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.4        rstudioapi_0.11   magrittr_1.5      usethis_1.5.1    
 [5] devtools_2.2.2    pkgload_1.0.2     R6_2.4.1          rlang_0.4.5      
 [9] fansi_0.4.1       tools_3.6.3       pkgbuild_1.0.6    sessioninfo_1.1.1
[13] cli_2.0.2         withr_2.1.2       ellipsis_0.3.0    remotes_2.1.1    
[17] assertthat_0.2.1  digest_0.6.25     rprojroot_1.3-2   crayon_1.3.4     
[21] processx_3.4.2    callr_3.4.3       fs_1.3.2          ps_1.3.2         
[25] curl_4.3          testthat_2.3.2    memoise_1.1.0     glue_1.3.2       
[29] compiler_3.6.3    desc_1.2.0        backports_1.1.5   prettyunits_1.1.1

Cheers and thanks in advance!

The error means you do not have the PROJ.4 library installed; it is the backend that handles various projection tasks (as you no doubt have guessed). {sf} requires three such backends - GDAL, PROJ and GEOS - to function correctly.

I am not a Mac user, but according to the documentation it might be handled by

brew install proj

on the command line.

2 Likes

Hi, and welcome!

Please see the FAQ: What's a reproducible example (`reprex`) and how do I do one? Using a reprex, complete with representative data will attract quicker and more answers. Not needed for this type of question, though.

The short answer is that things went south when accepting the offer to install from source. Sometimes things go smoothly, and often you get the dreaded non-zero exit status or, configuration failed.

This is due to Apple's non-standard compiler. St. Simon Urbanek of the R Core Development Team relieves MAC users like us of the brain damage required to edit the source code to allow it to compile on our machines and provides binary versions. Normally, this takes 7-10 days after a new CRAN version appears. devtools versions don't get that love, however.

I'm happily using sf_0.8-1 in binary, and it happily chirps Linking to GEOS 3.7.2, GDAL 2.4.2, PROJ 5.2.0.

Thanks!

I'll give the reprex section a read, thanks for sharing it :slight_smile:

Your reply was super interesting to read! Considering what you said, that sf 0.8-1 works in my computer, and the fact I'm not in dire need of using version 0.9-0, waiting for the binary version seems like the way to go :slight_smile:

Thanks again :smiley:

1 Like

Same thing here; trying to install sf 0.9-0 on macOS Catalina. If I run this command:

% brew install proj      
Warning: proj 7.0.0 is already installed and up-to-date
To reinstall 7.0.0, run `brew reinstall proj`

Reinstalling doesn't work either. I too shall wait for the binary to be released...

1 Like

That's a relief! xD

I'm a newbie in spatial analyses/packages so I was defaulting to trying to get the most recent package versions I could. I'm happy to hear that not being 100% up-to-date won't be such a hassle :slight_smile:

In case you need to use version 0.9-0 it installs properly on rstudio.cloud :slight_smile:

1 Like

Hi, and welcome!

Thanks for the contribution. We who are on macOS pay a price to hang on to all the polished conveniences and consistent conventions. This is a great example.

FYI for any coding questions: Please see the FAQ: What's a reproducible example (`reprex`) and how do I do one? Using a reprex, complete with representative data will attract quicker and more answers.

I must say, I very rarely run into troubles with macOS and it provided me a tremendous boost of productivity compared to the very same work I did for years on Windows and Linux. It's worth every penny :slight_smile:

1 Like

Hi! I am trying to install the sf package and am running into the same problems. Is the only solution to wait for a binary version of proj?

Hi, and welcome!

Please see the FAQ: What's a reproducible example (`reprex`) and how do I do one? Using a reprex, complete with representative data will attract quicker and more answers. Not needed for this type of question.

You have two options:

  1. Decline the "compile from source" option and install the most recent binary version, which works just fine. Or
  2. Wait for the latest and greatest sf version to become available in binary before trying it out.

When I have a need to be on a later version than is currently avail in macOS in binary, I install it on one of my Linux machines. Also, consider that the very latest features for a package that a user hasn't yet become familiar with the basics of are unlikely to be needed. :grin:

This is what happens if you just say no:

  There is a binary version available but the source version is later:
   binary source needs_compilation
sf  0.8-1  0.9-0              TRUE

Do you want to install from sources the package which needs compilation? (Yes/no/cancel) n
trying URL 'http://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.6/sf_0.8-1.tgz'
Content type 'application/x-gzip' length 64283240 bytes (61.3 MB)
==================================================
downloaded 61.3 MB

library(sf)
Linking to GEOS 3.7.2, GDAL 2.4.2, PROJ 5.2.0

Hi :slight_smile:

On top of what @technocrat said, you can use rstudio.cloud if you need version 0.9-0, the installation there goes smoothly :slight_smile:

1 Like

And [insert self dope slap here], the reason is -- wait for it -- that rstudio cloud is running on Linux, not macOS!

Thank you so much. I was looking forward to making visualizations and spent awhile trying to install the package. Thanks again and stay safe!

1 Like

There's some discussion in these two github issues that may be helpful:

3 Likes

It worked! Thanks @mfherman!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

Thanks for the suggestion @jlacko! I do have PROJ.4 installed though so I guess it might be a detection issue...

Anyway, I think I'll wait for the binary in the light @technocrat's reply :slight_smile:

I've never found myself in such desperate need of the latest version that I set a hair-on-fire alarm to check every thirty minutes, myself. :grin:

Oki, makes perfect sense.

Should you feel the irrational need to live on the bleeding edge (and from what I am told PROJ.4 version 6.0.0 and higher are not for the faint of heart) you may have to specify the paths to GEOS, GDAL and PROJ manually via --configure-args.

In such case you might find this issue an interesting read: https://github.com/r-spatial/sf/issues/335#issuecomment-484985276