Sf: Error on Installation: PROJ available, but not `proj_api.h`

Created on 4 Mar 2020  Â·  13Comments  Â·  Source: r-spatial/sf

I am trying to install sf on Void Linux.

I have GEOS (3.7.1), GDAL (3.0.4), proj (6.3.1), and udunits (2.2.26) installed. The former three come with the OS and I compiled udunits from source. So all files should be in their "default" locations.

During configuration, R finds PROJ, but it doesn't seem to find proj_api.h, which is located in
/usr/include:

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/share/gdal/pcs.csv readable... no
checking GDAL: checking whether PROJ is available for linking:... yes
checking GDAL: checking whether PROJ is available fur running:... yes
checking proj_api.h usability... no
checking proj_api.h presence... no
checking for proj_api.h... no
configure: error: proj_api.h not found in standard or given locations.
ERROR: configuration failed for package ‘sf’

How can I check where R is looking for proj_api.h and tell it where to look instead?

Looking through previous issues, I saw that installing pkg-config solved the problem for some users, but I already have it installed, as well.

Most helpful comment

@wngrtn, I ran into the same issue when trying to install sf from CRAN on a Linux machine equipped with GDAL (3.0.4), proj (7.0.0). In my case, installing the package via

remotes::install_github("r-spatial/sf")

solved the issue.

All 13 comments

If you have proj 6.3.1, sf should use proj.h, not proj_api.h.

@edzer, thanks! But how do I tell sf to use proj.h during installation?

If proj is properly installed, it finds it by itself.

@wngrtn, I ran into the same issue when trying to install sf from CRAN on a Linux machine equipped with GDAL (3.0.4), proj (7.0.0). In my case, installing the package via

remotes::install_github("r-spatial/sf")

solved the issue.

@wngrtn yes, try that; also we need the complete output of configure to be able to say something.

Released sf 0.8-1 has the if test "${PROJV1}" = "6"; then test, so PROJ 7 takes the PROJ < 6 branch, I think.

(Maybe it could be useful here - I created two new docker images:

  1. https://hub.docker.com/repository/docker/jakubnowosad/rspatial_proj7 (with PROJ7, GDAL3, and GEOS3.8)
  2. https://hub.docker.com/repository/docker/jakubnowosad/geocompr_proj7 (the same as above, but also with a large selection of #rspatial packages, including sf)

Thanks! I'm doing source installs with PROJ 7.0.0, but don't see any proj.pc being installed, so all pkg-config proj calls are failing. Am I doing something wrong? Tried both configure and cmake installs of PROJ.

My proj.pc ends up in /usr/local/lib/pkgconfig, and did install from a source build of 7.0.0 2 March.

This is on my dockerfile with custom installs of everything; I needed to run configure in PROJ as

./configure --prefix=/opt/proj --datadir=/opt/share

otherwise it would break (without --datadir).

@fdetsch, thank you! I was able to install sf from the master branch using

remotes::install_github("r-spatial/sf")

@edzer could your problem with proj.pc https://github.com/r-spatial/sf/issues/1288#issuecomment-597655431 be solved with this fix? I ran in a similar issue while upgrading to Proj 7.0.0 and sf from CRAN and I fixed it this way.

Yes, specifying --datadir in the PROJ install fixed it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Nosferican picture Nosferican  Â·  3Comments

kendonB picture kendonB  Â·  3Comments

jmsigner picture jmsigner  Â·  4Comments

tiernanmartin picture tiernanmartin  Â·  3Comments

kendonB picture kendonB  Â·  4Comments