Closed benz0li closed 1 year ago
FWIW, I get the same installation failure on Ubuntu 20.04 (which is based on bullseye).
Output from sf::sf_extSoftVersion()
:
GEOS GDAL proj.4 GDAL_with_GEOS USE_PROJ_H PROJ
"3.8.0" "3.0.4" "6.3.1" "true" "true" "6.3.1"
Thanks, that should now work.
I can confirm it was broken and it works now with :
sessionInfo()
#> R version 4.2.2 (2022-10-31)
#> Platform: x86_64-pc-linux-gnu (64-bit)
#> Running under: Debian GNU/Linux 11 (bullseye)
#>
#> Matrix products: default
#> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
#> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
#>
#> locale:
#> [1] LC_CTYPE=fr_FR.UTF-8 LC_NUMERIC=C
#> [3] LC_TIME=fr_FR.UTF-8 LC_COLLATE=fr_FR.UTF-8
#> [5] LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES=fr_FR.UTF-8
#> [7] LC_PAPER=fr_FR.UTF-8 LC_NAME=C
#> [9] LC_ADDRESS=C LC_TELEPHONE=C
#> [11] LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C
#>
#> attached base packages:
#> [1] stats graphics grDevices utils datasets methods base
#>
#> loaded via a namespace (and not attached):
#> [1] digest_0.6.31 withr_2.5.0 R.methodsS3_1.8.2 lifecycle_1.0.3
#> [5] magrittr_2.0.3 reprex_2.0.2 evaluate_0.20 rlang_1.0.6
#> [9] cli_3.6.0 rstudioapi_0.14 fs_1.6.1 R.utils_2.12.2
#> [13] R.oo_1.25.0 vctrs_0.5.2 styler_1.9.1 rmarkdown_2.20
#> [17] tools_4.2.2 R.cache_0.16.0 glue_1.6.2 purrr_1.0.1
#> [21] xfun_0.37 yaml_2.3.7 fastmap_1.1.1 compiler_4.2.2
#> [25] htmltools_0.5.4 knitr_1.42
Created on 2023-03-13 with reprex v2.0.2
sf::sf_extSoftVersion()
#> GEOS GDAL proj.4 GDAL_with_GEOS USE_PROJ_H
#> "3.9.0" "3.2.2" "7.2.1" "true" "true"
#> PROJ
#> "7.2.1"
Created on 2023-03-13 with reprex v2.0.2
I get the same error as the OP for the source install on Windows:
c:\rtools42\x86_64-w64-mingw32.static.posix\include\ogr_spatialref.h:258:17: note: candidate expects 3 arguments, 4 provided
make: *** [C:/PROGRA~1/R/R-42~1.2/etc/x64/Makeconf:260: gdal.o] Error 1
This seems to be fixed in the dev version, but I get another error when trying to install that dev version.
g++ -std=gnu++11 -shared -s -static-libgcc -o sf.dll tmp.def RcppExports.o bbox.o gdal.o gdal_geom.o gdal_read.o gdal_utils.o gdal_write.o geos.o hex.o mdim.o ops.o polygonize.o proj.o proj_info.o raster2sf.o sfc-sfg.o signed_area.o stars.o wkb.o zm_range.o -fopenmp -lgdal -larmadillo -lopenblas -lgfortran -lquadmath -lpq -lpgcommon -lpgport -lodbc32 -lodbccp32 -lblosc -lkea -lhdf5_cpp -lhdf5 -lpoppler -llcms2 -lfreetype -lharfbuzz -lfreetype -llz4 -lpcre2-8 -lxml2 -lopenjp2 -lnetcdf -lmysqlclient -lspatialite -lgeos_c -lgeos -lminizip -lgeos -ljson-c -lgta -lfreexl -lexpat -lssl -lpsapi -lgif -lmfhdf -lhdf5_hl -lcrypto -lportablexdr -ldf -lhdf5 -lsz -lpng16 -lpng -lpoppler -llcms2 -lfreetype -lharfbuzz -lfreetype -llz4 -lpcre2-8 -lpcre -lcurl -lbcrypt -lrtmp -lssl -lssh2 -lidn2 -lunistring -liconv -lgcrypt -lcrypto -lgpg-error -lws2_32 -ltiff -llzma -ljpeg -lz -lcfitsio -lzstd -lwebpdecoder -lwebp -lsbml-static -lgeotiff -lproj -lsqlite3 -lbz2 -lcrypt32 -lwldap32 -lsecur32 -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib -LC:/PROGRA~1/R/R-42~1.2/bin/x64 -lR
C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lblosc
C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lkea
C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lsz
collect2.exe: error: ld returned 1 exit status
no DLL was created
@dpprdan blosc and kea were added in rtools42 revision 5355: https://cran.r-project.org/bin/windows/Rtools/rtools42/news.html
@edzer Thanks, the latest rtools42 did it, and sorry for the extra work!
I guess, I still had rtools42-5168-5107.exe installed.
This is extra ☹️, because I had a hunch that it might be due to Rtools and wanted to report its version, but apparently that cannot be easily queried. Rtools not being fully versioned (i.e. it's displaying the same ARP entry for all 4.2 versions) does not help much either, I suppose (not least because else it would have been updated via winget on my machine).
Thanks, that should now work.
@edzer I will close this issue as soon as https://cran.r-project.org/package=sf is updated to a new version allowing to install on Debian 11.
Is a release with this fix something that will happen soon-ish? I'm noticing it affects all of the revdep check machinery used by the tidyverse team, meaning we fail to check anything that depends on sf, directly or indirectly. I can imagine a workaround that would install dev sf, but if this will self-resolve pretty quickly, that's even better.
Update: it is a hypothesis that this is why sf is failing to install. It could also be something else, but it's hard for me to get more detailed information.
The main problem is the use of GDAL< 3.0.4. 3.6.3 was released recently, 3.7.0 is imminent. A check for a needed function from GDAL tested against 3.0.0, should have been 3.0.4, is with @edzer 's commit yesterday.
should have been 3.0.4
no, 3.4.0, which is quite a leap. Will try to get a fix on CRAN soon!
Just to follow up, I did eventually dig deep enough to confirm that, yeah, this is the problem, in terms of our revdep check tooling.
Will try to get a fix on CRAN soon!
1.0-11 submitted!
1.0-11 submitted!
Rejected: https://nx10.github.io/cransubs/pkg#sf_2023-03-14T21%3A08%3A06Z
No, accepted.
@edzer Thank you.
Describe the bug
Installation fails on Debian 11 (bullseye) for sf v1.0-10.
To Reproduce
Execute
with the following
Dockerfile
:If reporting a change from previous versions
Please read https://cran.r-project.org/web/packages/sf/news/news.html first.
Additional context
Installation log (excerpt):
ℹ️ See also https://gitlab.b-data.ch/r/geospatial/-/jobs/52911.
(Installation succeeds for the 'Ubuntu 22.04 (Jammy)'-based, GPU accelerated image: https://gitlab.b-data.ch/cuda/r/geospatial/-/jobs/52901)