sf
sf copied to clipboard
r-spatial
configure error on M1 Mac (12.5) w/ homebrew libs
Describe the bug
Attempting to install sf (and terra) I get the following error from configure:
~/tmp/sf » R CMD install . rundel@magsafe
* installing to library ‘/Users/rundel/Library/R/arm64/4.2/library’
* installing *source* package ‘sf’ ...
file ‘configure’ has the wrong MD5 checksum
** using staged installation
configure: CC: clang
configure: CXX: clang++ -std=gnu++11
checking for gdal-config... /opt/homebrew/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 3.5.1
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 the compiler supports GNU C... yes
checking whether clang accepts -g... yes
checking for clang option to enable C11 features... none needed
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for gdal.h... yes
checking GDAL: linking with --libs only... yes
checking GDAL: /opt/homebrew/Cellar/gdal/3.5.1_1/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
configure: GDAL: 3.5.1
configure: pkg-config proj exists, will use it
configure: using proj.h.
configure: PROJ: 9.0.1
checking PROJ: checking whether PROJ and sqlite3 are available for linking:... no
configure: error: libproj or sqlite3 not found in standard or given locations.
ERROR: configuration failed for package ‘sf’
The specific issue is caused by the inclusion of -ljpeg in ${LIBS} without the inclusion of the necessary -L flag to find this library, so the following error is reported:
~/tmp/sf » more errors.txt 1 ↵ rundel@magsafe
ld: library not found for -ljpeg
clang: error: linker command failed with exit code 1 (use -v to see invocation)
This seems in part related to how homebrew has configured pkg-config which is pulling this specific library in due to proj -> libtiff-4 -> jpeg with libtiff bringing in the -l flag and not the -L flag. While this could be take up with the homebrew folks this seems like an unnecessary use of the --static flag with pkg-config for proj - see https://github.com/r-spatial/sf/blob/e0eeaa1e70522f4a7cdb439909e6151dbae5b029/configure.ac#L398
Removing --static here allows for configure to complete successfully and the package to be installed and everything seems to be working.
Additional context
This seems to be related to #1696 and potentially some of the changes made to address it. From a brief survey of configure.ac I'm not sure why static would be needed since the package and everything else are being dynamically linked.
The homebrew on the laptop configuration is standard - happy to provide specific versions and details if helpful.
Matrix products: default BLAS: /opt/homebrew/Cellar/openblas/0.3.21/lib/libopenblasp-r0.3.21.dylib LAPACK: /opt/homebrew/Cellar/r/4.2.1_2/lib/R/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.9 magrittr_2.0.3 units_0.8-0 tidyselect_1.1.2 [5] R6_2.5.1 rlang_1.0.4 fansi_1.0.3 dplyr_1.0.9 [9] tools_4.2.1 grid_4.2.1 KernSmooth_2.23-20 utf8_1.2.2 [13] cli_3.3.0 e1071_1.7-11 DBI_1.1.3 class_7.3-20 [17] assertthat_0.2.1 tibble_3.1.8 lifecycle_1.0.1 sf_1.0-8 [21] purrr_0.3.4 vctrs_0.4.1 glue_1.6.2 proxy_0.4-27 [25] compiler_4.2.1 pillar_1.8.0 generics_0.1.3 classInt_0.4-7 [29] pkgconfig_2.0.3
sf:::sf_extSoftVersion() GEOS GDAL proj.4 GDAL_with_GEOS USE_PROJ_H "3.11.0" "3.5.1" "9.0.1" "true" "true" PROJ "9.0.1"
</details>
Have you seen https://github.com/r-spatial/sf/issues/1894? I also tried to debug the source of the issue but your solution sounds really promising and more than a workaround! (the same issue also applies to {terra} btw).
Curious to see this discussion going forward!
The --static flag may be needed because CRAN binaries are all statically linked; to remove it we might have to branch on whether we're in a homebrew setting or in a CRAN build setting.
What might help here is to understand the configuration of jpeg in contrast to proj, sqlite3, gdal and others in the current setup, no matter if static or dynamic.
- what makes it being treated differently when it comes to homebrew vs cran linking?
- can changes in the configure script resolve it?
- is the issue on the homebrew side?
At least we've tracked down the issue now being related to jpeg and not to proj or sqlite as the error message indicates.
PROJ >= 7 needs libtiff to handle CDN transformation grid files, libsqlite3, and libcurl for handling CDN communication. In a dynamic configure testing setting, all would be found by libproj, in static, all the upstream need to be listed (as in MXE etc. or recipes). It feels as though homebrew libtiff static is built depending on libjpeg. https://formulae.brew.sh/formula/libtiff says:
Depends on: jpeg-turbo 2.1.3 JPEG image codec that aids compression and decompression
So a choice homebrew itself makes, as does Rtools42: https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/tiff.mk.
On Fedora 36 with PROJ built from source with Cmake, I see:
$ pkg-config --libs --static proj
-L/usr/local/lib64 -lproj -lstdc++ -lm -ldl -lsqlite3 -lm -lz -ltiff -lwebp -lzstd -ljbig -ljpeg -lz -lm -lcurl -lnghttp2 -lidn2 -lssh -lssh -lpsl -lssl -lcrypto -lssl -lcrypto -lgssapi_krb5 -lldap -llber -lbrotlidec -lbrotlidec -lz
