library(sf) loads wrong version of GEOS
dbaston opened this issue · 42 comments
I get the following error when building sf master against GEOS 3.7.0:
unable to load shared object '/home/dan/R/x86_64-pc-linux-gnu-library/3.4/sf/libs/sf.so':
/home/dan/R/x86_64-pc-linux-gnu-library/3.4/sf/libs/sf.so: undefined symbol: GEOSFrechetDistanceDensify_r
I verified that the symbol is present in libgeos_c.so:
nm -g /usr/local/lib/libgeos_c.so | grep Frechet
0000000000010210 T GEOSFrechetDistance
0000000000010230 T GEOSFrechetDistanceDensify
00000000000141e0 T GEOSFrechetDistanceDensify_r
0000000000014040 T GEOSFrechetDistance_r
The following command is used to link sf:
g++ -std=gnu++11 -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o sf.so RcppExports.o bbox.o gdal.o gdal_geom.o gdal_read.o gdal_utils.o gdal_write.o geos.o hex.o proj.o raster2sf.o sfg.o signed_area.o stars.o wkb.o -lproj -L/usr/local/lib -lgdal -L/usr/local/lib -lgeos_c -L/usr/lib/R/lib -lR
which looks right to me.
I've seen the same thing when testing against 3.7.0rc2, after Brian Ripley warned @rsbivand (rgeos) and me about it a few days ago. Will try again with 3.7.0. Big mystery!
I reproduced it again (in a container) with GEOS 3.7.0, and got the same error. In earlier attempts I tried to remove GEOSFrechetDistanceDensify_r, but then it would break on the next symbol, and so on; as you showed, the symbols are there. Did they do something with GEOS?
@edzer I'm able to build and run a dummy program using GEOSFrechetDistanceDensify_r:
#include <geos_c.h>
#include <iostream>
int main(int argc, char** argv) {
auto handle = initGEOS_r(nullptr, nullptr);
GEOSGeometry* geom1_ = GEOSGeomFromWKT_r(handle, "LINESTRING (0 0, 100 0)");
GEOSGeometry* geom2_ = GEOSGeomFromWKT_r(handle, "LINESTRING (0 0, 50 50, 100 0)");
double dist;
int ret = GEOSFrechetDistanceDensify_r(handle, geom1_, geom2_, 0.5, &dist);
std::cout << dist << std::endl;
}
with
g++ frechet.cpp -std=c++11 -o frechet -L /usr/local/lib -lgeos_c
Running ldd sf.so also shows correct output:
libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0x00007f4621c23000)
Yet, running the following:
LD_DEBUG=all LD_DEBUG_OUTPUT=/tmp/debug Rscript -e "dyn.load('/home/dan/dev/sf/src/sf.so')"
then
grep Frechet /tmp/debug*
shows that the wrong library is being loaded at runtime
/tmp/debug.28543: 28543: symbol=GEOSFrechetDistanceDensify_r; lookup in file=/usr/lib/x86_64-linux-gnu/libgeos_c.so.1
The link step of rgeos is
g++ -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o rgeos.so dummy.o init.o local_stubs.o rgeos.o rgeos_R2geos.o rgeos_R2geosMP.o rgeos_bbox.o rgeos_buffer.o rgeos_coord.o rgeos_geos2R.o rgeos_linearref.o rgeos_misc.o rgeos_poly2nb.o rgeos_predicate_binary.o rgeos_predicate_unary.o rgeos_topology.o rgeos_topology_binary.o rgeos_validate.o rgeos_wkt.o -L/usr/local/lib -lgeos-3.7.0 -L/usr/local/lib -lgeos_c -L/usr/lib/R/lib -lR
which includes -lgeos-3.7.0, not in sf.
adding this didn't solve the problem.
After moving /usr/lib/x86_64-linux-gnu/libgeos_c.so.1.9.1 and /usr/lib/x86_64-linux-gnu/libgeos_c.so.1 out of the way, sf installed fine.
Yes, multiple libgeos will probably cause havoc. I haven't seen any rgeos issues on Fedora, but always delete earlier /usr/local/lib/libgeos* etc., and never let any packager install GDAL, PROJ or GEOS. The warning from Brian Ripley may relate to static builds (libgeos.a), but configure.ac presupposes dynamic (libgeos-3.7.0):
[rsb@localhost geos-3.7.0]$ geos-config --cclibs
-L/usr/local/lib -lgeos
[rsb@localhost geos-3.7.0]$ geos-config --clibs
-L/usr/local/lib -lgeos_c
[rsb@localhost geos-3.7.0]$ geos-config --libs
-L/usr/local/lib -lgeos-3.7.0
[rsb@localhost geos-3.7.0]$ geos-config --static-clibs
-L/usr/local/lib -lgeos_c -lgeos -lm
[rsb@localhost geos-3.7.0]$ geos-config --static-cclibs
-L/usr/local/lib -lgeos -lm
and configure.ac has:
GEOS_LIBS=`${GEOS_CONFIG} --libs`
GEOS_CLIBS=`${GEOS_CONFIG} --clibs`
Please advise on any need to change configure.ac.
rgeos configure.ac committed with:
GEOS_LIBS=`${GEOS_CONFIG} --cclibs`
GEOS_CLIBS=`${GEOS_CONFIG} --clibs`
configure controls compilation, but the error occurs at runtime. I can't think of a way in which configure could change this.
But it removes the version suffix from the rgeos link step. Beyond that, the loader will use the first libgeom it finds. I'm not seeing any issues on Fedora, feels like a platform issue. Time someone made a Fedora rocker for improved stability?
I think the issue Can't build against GEOS 3.7.0 is not true; the issue Can't build against GEOS 3.7.0 if there is also another GEOS installation on my system is, depending on where it is. Some diagnostics:
When hacking geos.cpp such that it doesn't use symbols provided only by GEOS 3.7.0 or 3.6.1, it compiles AND loads on R when GEOS 3.7.0 is in /usr/local/lib and GEOS 3.5.1 (or so) is in /usr/lib/something. Then:
root@313b7b08657b:/# ldd /usr/local/lib/R/site-library/sf/libs/sf.so | grep geos
libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0x00007fb39962a000)
libgeos-3.7.0.so => /usr/local/lib/libgeos-3.7.0.so (0x00007fb3964d2000)
root@313b7b08657b:/# echo $LD_LIBRARY_PATH
/usr/local/lib:
but after starting R:
> system("ldd /usr/local/lib/R/site-library/sf/libs/sf.so | grep geos")
libgeos_c.so.1 => /usr/lib/x86_64-linux-gnu/libgeos_c.so.1 (0x00007fdad7954000)
libgeos-3.5.1.so => /usr/lib/x86_64-linux-gnu/libgeos-3.5.1.so (0x00007fdad481d000)
> Sys.getenv("LD_LIBRARY_PATH")
[1] "/usr/lib/R/lib:/usr/lib/x86_64-linux-gnu:/usr/lib/jvm/default-java/jre/lib/amd64/server:/usr/local/lib:"
A hacky solution to this might be
> Sys.setenv(LD_LIBRARY_PATH="/usr/local/lib:/usr/lib/R/lib:/usr/lib/x86_64-linux-gnu:/usr/lib/jvm/default-java/jre/lib/amd64/server:")
> system("ldd /usr/local/lib/R/site-library/sf/libs/sf.so | grep geos")
libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0x00007f4909bc1000)
libgeos-3.7.0.so => /usr/local/lib/libgeos-3.7.0.so (0x00007f4906a69000)
but I'm not sure if I would go as far as recommending this to anyone.
It would actually be good (sane, secure) to do a run-time check that the GEOS version linked to corresponds to the one found at compile time.
In rgdal this is done on attach (maybe should be done on load?) using GDALCheckVersion(); does GEOS provide a similar function?
Gives me:
> library(sf)
Linking to GEOS 3.7.0, GDAL 2.4.0dev-358fa65, proj.4 5.1.0
WARNING: different compile-time and runtime versions for GEOSI'll try to improve this: the linking to GEOS info is wrong.
Gives:
> library(sf)
Linking to GEOS 3.5.1, GDAL 2.4.0dev-358fa65, PROJ 5.1.0
WARNING: different compile-time and runtime versions for GEOS found:
Linked against: 3.5.1-CAPI-1.9.1 r4246 compiled against: 3.7.0-CAPI-1.11.0
I've committed to rgeos as r576, but found that my loader itself stopped the package loading when the versions differed:
> library(rgeos)
Error: package or namespace load failed for ‘rgeos’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/rsb/lib/r_libs/rgeos/libs/rgeos.so':
libgeos-3.7.0.so: cannot open shared object file: No such file or directory
but had replaced 3.7.0 with 3.6.3. In your case, I assume that both were present but libgeos was linked to another version?
Yes, it is more likely to get a load error than a version mismatch warning, but nevertheless useful to check IMO. In my case both are present and in LD_LIBRARY_PATH. R changed LD_LIBRARY_PATH by putting stuff in front of the user-set value, and that caused the havoc.
Everything works ok if I explicitly load GEOS before sf, with:
dyn.load('/usr/local/lib/libgeos_c.so', local=FALSE)
library(sf)
But putting a dyn.load into the .onLoad function seems to be "too late."
Thanks! Now that we know all this, I'm thinking about writing a short wiki entry, and make a link to it from the README.md file.
@edzer I'm running into similar issues, any progress on the wiki entry to help describe this issue or how to avoid it?
I just faced these errors on CentOS7 with source installation of GDAL, GEOS and PROJ.
It looks like the source of all error is the directory in which all the dynamic files are installed.
Setting the config option --libdir=/usr/lib64 solved all problems and I got clean installs of rgdal and sf.
- GDAL 2.4.0
- Proj 5.2.0
- GEOS 3.7.1
Maybe even worth a blog post including the installation scripts.
@pat-s how did you notice that a different version was dynamically loaded than the one that was linked to at compile time? What happened when you did not set --libdir=/usr/lib64?
I did not have multiple source installations actually. I think the conflicting part may have been that I still had the headers of the respective libs installed via their <lib>-devel rpm files.
Long story
In my first attempt, I got errors bc the header files of the respective libs were missing.
So I installed them along the source installations of GDAL, GEOS and PROJ.
Then, rgdal complained that it cannot find libgdal.so.20.
The file was stored in /usr/local/lib.
I found this SO post and it suggested that rgdal searches in /usr/lib64.
So initially I just copied the file there to see if it works.
It worked and I could install rgdal.
However, then sf failed with the GEOS error above.
I thought: "Ok, let's just install all of the three with the libdir option set to /usr/lib64" and yes - it worked.
I could install sf and rgdal without any warning even.
So maybe this error is manyfold: Having either multiple source installations or a mix of source installation files and header files from the package manager (which maybe used if the libdir of the source install is not correct).
However, the last is just a spurious assumption and not really checked.
I think it varies among OS how to set libdir. But for CentOS this might be the solution. I also do not see many alternatives than building from source on CentOS as the standard repos are very outdated and there are no projects like ubuntugisunstable as for Ubuntu etc.
I know this is a closed issue, so this comment might not be seen... but this is the closest discussion I've found that matches my problem.
I work in an enterprise environment where R is installed on a single server, and we all access it via RStudio Server Pro. I have no control, then, over the various versions of things, and have resorted to installing newer versions of key libraries in my home directory, while adjusting PATH and LD_LIBRARY_PATH as appropriate. This hasn't caused me any problems whatsoever until I installed newer versions of GEOS, GDAL and Proj.
Our server has GEOS 3.5.1 (and GDAL 2.1.x), and I have installed GEOS 3.8.1 (and GDAL 3.1.1) in my home directory. Basically, I now can't install rgeos, or any other package that depends on GEOS, in the usual way. During configuration and build, rgeos very clearly uses GEOS 3.8.1, but it seems that R tries to load 3.5.1 during checks, and only during checks. I can get a correctly functioning rgeos that uses my personal GEOS installation if I install via:
R CMD INSTALL rgeos_0.5-3.tar.gz --no-test-loadI also then have to install any other package that depends on GEOS using this same method, but the installed package always works correctly. It's driving me crazy and I hoped somebody with a better understanding of the load hooks knows why R was loading the wrong GEOS library, but only during package install tests.
Anyway, if anybody sees this, I'd be grateful for any suggestions; and I'll look for an rgeos forum to post this also.
You need to set LD_LIBRARY_PATH to have a program load dynamic libraries from custom locations; IIRC R resets it itself so you're lost setting it before starting R. See my notes mentioning it above. There may be a better way of doing this, but I found the one I got to (setting LD_LIBRARY_PATH from inside the R session before loading packages) too ugly to document publicly.
Thanks for the very fast response. I did see that comment, but I had checked Sys.getenv("LD_LIBRARY_PATH") from inside my session just prior to install and it was correct and so thought it was specifically an issue with R's install checks. I'll take another run at it.
I think I'll just have to admit defeat...
> Sys.setenv("LD_LIBRARY_PATH" = "/home/STATSNZ/cxhansen/usr/lib:...)
> Sys.getenv("LD_LIBRARY_PATH")
[1] "/home/STATSNZ/cxhansen/usr/lib:/usr/lib/x86_64-linux-gnu:/usr/lib/jvm/default-java/jre/lib/amd64/server"
> dyn.load("rgeos.so")
Error in dyn.load("rgeos.so") :
unable to load shared object '/home/STATSNZ/cxhansen/src/rgeos/src/rgeos.so':
/home/STATSNZ/cxhansen/src/rgeos/src/rgeos.so: undefined symbol: GEOSMakeValid_r
> system("ldd rgeos.so | grep libgeos")
libgeos_c.so.1 => /home/STATSNZ/cxhansen/usr/lib/libgeos_c.so.1 (0x00007fc19ccbf000)
libgeos-3.8.1.so => /home/STATSNZ/cxhansen/usr/lib/libgeos-3.8.1.so (0x00007fc19c8eb000)
> system("nm -D /home/STATSNZ/cxhansen/usr/lib/libgeos_c.so.1 | grep GEOSMakeValid_r")
000000000001dbd0 T GEOSMakeValid_r
@cmhh does loading GEOS explicitly not work for you, like here? #844 (comment)
I added this line to my .Rprofile and I've had no problems since.
@dbaston No it didn't. That is to say, I can install using the method described above (setting --no-test-load), but not in the usual way (either without that flag, or using install.packages from R). Anyway, I ran the following from the terminal:
export LD_DEBUG=libs
R CMD INSTALL rgeos_0.5-3.tar.gz and here's a chunk of the output:
7887: find library=libgeos_c.so.1 [0]; searching
7887: trying file=/usr/lib/R/lib/libgeos_c.so.1
7887: trying file=/usr/lib/x86_64-linux-gnu/libgeos_c.so.1
7887: find library=libgeos-3.5.1.so [0]; searching
7887: trying file=/usr/lib/R/lib/libgeos-3.5.1.so
7887: trying file=/usr/lib/x86_64-linux-gnu/libgeos-3.5.1.so
7887: /home/STATSNZ/cxhansen/My-R-User-Libraries/00LOCK-rgeos/00new/rgeos/libs/rgeos.so: error: symbol lookup error: undefined symbol: GEOSMakeValid_r (fatal)
I have set LD_LIBRARY_PATH to search ~/usr/lib first in ~/.profile, ~/.bashrc, and ~/.Renviron. For the life of me I don't know why R isn't looking where I asked it to first. Again, rgeos.so is built correctly, but when R does the bit where it checks the .so file is loadable, it seems to ignore LD_LIBRARY_PATH. Again, I'm just going to have to accept defeat here, I think.
@dbaston Hold the phone... it seems my .Rprofile file was called .RProfile for some reason, and renaming it to .Rprofile seems to be working! It currently has the following content:
Sys.setenv("LD_LIBRARY_PATH" = "/home/STATSNZ/cxhansen/usr/lib:/usr/lib/x86_64-linux-gnu:/usr/lib/jvm/default-java/jre/lib/amd64/server")
dyn.load("/home/STATSNZ/cxhansen/usr/lib/libgeos-3.8.1.so")
dyn.load("/home/STATSNZ/cxhansen/usr/lib/libgeos_c.so")
Thanks!
Had a lot of trouble getting 'sf' package to install on Red Hat/CentOS 7:
I first tried to run install.packages('sf') and it complained about gdal being missing, so I installed gdal using sudo yum install gdal-devel, but that installed 1.11.4 which is too old. So I ran sudo yum erase gdal-devel to remove.
I then ran the following to install a newer version (following instructions from somewhere I do not recall):
sudo yum install libproj-devel
sudo yum groupinstall "Development Tools"
and installed GDAL from source:
wget http://download.osgeo.org/gdal/2.4.1/gdal-2.4.1.tar.gz
tar xzf gdal-2.4.1.tar.gz
cd gdal-2.4.1
Compile from source
./configure --with-libkml
sudo make
sudo make install
then the installer (running as sudo R) couldn't find gdal-config, so I created a symlink to it in the sudo path (different from my user path): sudo ln -s /usr/local/bin/gdal-config /bin/gdal-config
Next installer error: cannot find proj/epsg, so run: sudo yum install proj-epsg.
Next installer error: cannot find geos-config so run: sudo yum install geos-devel
Now appears to be installed and working.
I found this issue page via https://github.com/r-spatial/sf, but that page doesn't include CentOS 7 install steps. Would be nice to add CentOS steps to that page.
@rsbivand Confirming that removing older libgeos files in /usr/local/lib resolved dynamic library load test failure at the end of the build process for packages sf and rgdal on Ubuntu 20.04
You may have the proper versions of libgdal-dev, libproj-dev, libgeos-dev but fail during the last steps of the build when it attempts to load the wrong version of the shared library. For me it was not obvious until I spent a significant amount of time digging around.
This is perhaps off target, but may be related. I raise it here both to ask for advice and to flag that I believe that the issue is created by following the standard installion instructions for sf and QGIS...
My situation
I have sf working fine on Ubuntu 20.04.4 LTS, but I'm having problems with my QGIS installation. I think this is because of multiple libproj installations (see here for details of the issue I think I have).
find -iname libproj* returns that I have a whole host of libproj installations in various locations (oops). Amazingly, sf seems ok with this (for now...).
./usr/lib/x86_64-linux-gnu/libproj.a
./usr/lib/x86_64-linux-gnu/libproj.so
./usr/lib/x86_64-linux-gnu/libproj.so.15
./usr/lib/x86_64-linux-gnu/libproj.so.22
./usr/lib/x86_64-linux-gnu/libproj.la
./usr/lib/x86_64-linux-gnu/libproj.so.22.2.0
./usr/lib/x86_64-linux-gnu/libproj.so.15.3.1
./usr/share/doc/libproj-dev
./usr/share/doc/libproj22
./usr/share/doc/libproj15
How this came to be
I believe installing QGIS created the initial ./usr/lib/x86_64-linux-gnu/
I then installed sf, but my understanding is that sf needs the -dev version, so must have created the ./usr/share/doc/ versions
It's at this point that QGIS stopped finding PROJ...
I suspect I then somehow created the second ./usr/lib/x86_64-linux-gnu/ version trying to fix QGIS not finding PROJ (I first took the error literally and thought it was not installed)...
My question(s)
I want to fix QGIS without breaking sf...
I clearly need to delete a few versions to fix QGIS, but which one is sf using? Am I correct in saying that sf will be using ./usr/share/doc/libproj-dev? Alternatively, how do I find out which one sf is using? Should I delete ./usr/share/doc/libproj15 and ./usr/share/doc/libproj22 or keep all 3 in that location?
My temptation is to delete all the ./usr/lib/x86_64-linux-gnu/ versions and hope for the best?
Any suggestions greatly appreciated!
Thanks!
Hello! I'm having the same issue as in these posts, yet am using RedHat 8, and cannot use some of the suggested solutions. I have deleted any gdal instance I can find on the server and reinstalled several times to no avail.
So far, my primary attempts have gone like this:
sudo yum install gdal-devel
sudo yum install proj-devel
sudo yum install geos-devel
And in sudo R:
> install.packages("sf")
Installing package into ‘/usr/lib64/R/library’
(as ‘lib’ is unspecified)
trying URL 'https://ftp.osuosl.org/pub/cran/src/contrib/sf_1.0-14.tar.gz'
Content type 'application/x-gzip' length 3488161 bytes (3.3 MB)
==================================================
downloaded 3.3 MB
* installing *source* package ‘sf’ ...
** package ‘sf’ successfully unpacked and MD5 sums checked
** using staged installation
configure: CC: gcc
configure: CXX: g++ -std=gnu++17
checking for gdal-config... /bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 3.0.4
checking GDAL version >= 2.0.1... yes
checking for gcc... gcc
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 gcc accepts -g... yes
checking for gcc 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: /usr/share/gdal/pcs.csv readable... no
checking GDAL: checking whether PROJ is available for linking:... yes
checking GDAL: checking whether PROJ is available for running:... yes
configure: GDAL: 3.0.4
configure: pkg-config proj exists, will use it
configure: using proj.h.
configure: PROJ: 6.3.2
checking PROJ: checking whether PROJ and sqlite3 are available for linking:... yes
checking for geos-config... /bin/geos-config
checking geos-config usability... yes
configure: GEOS: 3.7.2
checking GEOS version >= 3.4.0... yes
checking for geos_c.h... yes
checking geos: linking with -L/usr/lib64 -lgeos_c... yes
configure: Package CPP flags: -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include
configure: Package LIBS: -lproj -L/usr/lib64 -lgdal -L/usr/lib64 -lgeos_c
configure: creating ./config.status
config.status: creating src/Makevars
** libs
using C++ compiler: ‘g++ (GCC) 8.5.0 20210514 (Red Hat 8.5.0-18)’
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c bbox.cpp -o bbox.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c gdal.cpp -o gdal.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c gdal_geom.cpp -o gdal_geom.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c gdal_read.cpp -o gdal_read.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c gdal_utils.cpp -o gdal_utils.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c gdal_write.cpp -o gdal_write.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c geos.cpp -o geos.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c hex.cpp -o hex.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c mdim.cpp -o mdim.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c ops.cpp -o ops.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c polygonize.cpp -o polygonize.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c proj.cpp -o proj.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c proj_info.cpp -o proj_info.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c raster2sf.cpp -o raster2sf.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c sfc-sfg.cpp -o sfc-sfg.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c signed_area.cpp -o signed_area.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c stars.cpp -o stars.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c wkb.cpp -o wkb.o
g++ -std=gnu++17 -I"/usr/include/R" -DNDEBUG -DHAVE_PROJ_H -I/usr/include/gdal -I/usr/include -I'/usr/lib64/R/library/Rcpp/include' -I/usr/local/include -fpic -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c zm_range.cpp -o zm_range.o
g++ -std=gnu++17 -shared -L/usr/lib64/R/lib -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o sf.so 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 -lproj -L/usr/lib64 -lgdal -L/usr/lib64 -lgeos_c -L/usr/lib64/R/lib -lR
installing to /usr/lib64/R/library/00LOCK-sf/00new/sf/libs
** R
** demo
** inst
** byte-compile and prepare package for lazy loading
in method for ‘dbWriteTable’ with signature ‘"PostgreSQLConnection","character","sf"’: no definition for class “PostgreSQLConnection”
in method for ‘dbDataType’ with signature ‘"PostgreSQLConnection","sf"’: no definition for class “PostgreSQLConnection”
in method for ‘coerce’ with signature ‘"Spatial","sf"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"Spatial","sfc"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"sf","Spatial"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"sfc","Spatial"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"XY","Spatial"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"crs","CRS"’: no definition for class “CRS”
in method for ‘coerce’ with signature ‘"sgbp","sparseMatrix"’: no definition for class “sparseMatrix”
** help
*** installing help indices
converting help for package ‘sf’
finding HTML links ... done
Ops html
aggregate.sf html
bind html
coerce-methods html
dbDataType html
dbWriteTable html
db_drivers html
extension_map html
gdal html
gdal_addo html
gdal_utils html
geos_binary_ops html
geos_binary_pred html
geos_combine html
geos_measures html
geos_query html
geos_unary html
internal html
interpolate_aw html
is_driver_available html
is_driver_can html
is_geometry_column html
merge.sf html
nc html
plot html
prefix_map html
proj_tools html
rawToHex html
reexports html
s2 html
sf-defunct html
sf html
sf_extSoftVersion html
sf_project html
sfc html
sgbp html
st html
st_agr html
st_as_binary html
st_as_grob html
st_as_sf html
st_as_sfc html
st_as_text html
st_bbox html
st_break_antimeridian html
st_cast html
st_cast_sfc_default html
st_collection_extract html
st_coordinates html
st_crop html
st_crs html
st_drivers html
st_geometry html
st_geometry_type html
st_graticule html
st_is html
st_is_longlat html
st_jitter html
st_join html
st_layers html
st_line_sample html
st_m_range html
st_make_grid html
st_nearest_feature html
st_nearest_points html
st_normalize html
st_precision html
st_read html
st_relate html
st_sample html
st_shift_longitude html
st_transform html
st_viewport html
st_write html
finding level-2 HTML links ... done
st_z_range html
st_zm html
stars html
summary.sfc html
tibble html
tidyverse html
transform.sf html
valid html
vctrs html
*** copying figures
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘sf’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/usr/lib64/R/library/00LOCK-sf/00new/sf/libs/sf.so':
/usr/lib64/R/library/00LOCK-sf/00new/sf/libs/sf.so: undefined symbol: proj_context_set_enable_network
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/usr/lib64/R/library/sf’
The downloaded source packages are in
‘/tmp/Rtmpr1e6D5/downloaded_packages’
Updating HTML index of packages in '.Library'
Making 'packages.html' ... done
Warning message:
In install.packages("sf") :
installation of package ‘sf’ had non-zero exit status
Any help on where to look for duplicated gdal instances would be much appreciated. I have deleted as many as I can locate but with no success.
I think that proj_context_set_enable_network is only available in PROJ >= 7 https://proj.org/en/9.2/development/reference/functions.html. Try to install a less ancient PROJ and GDAL.
Thank you @rsbivand . Your answer helped very much. For whatever reason the yum install of proj-devel is years behind and it definitely needs to be installed from source.
I followed this tutorial on installing the geospatial libraries from source, which was quite helpful and includes some troubleshooting options: https://docs.djangoproject.com/en/4.2/ref/contrib/gis/install/geolibs/
And I modified the sf installation to locate the gdal, proj, and geos install files that sf needs manually.
install.packages(pkgs= "sf", type = "source", configure.args = c("--with-gdal-config=/usr/local/bin/gdal-config", "--with-proj-lib=/usr/local/lib64", "--with-proj-include=/usr/local/include", "--with-geos-config=/usr/local/bin/geos-config"))
Thanks!
Hi, I have a quick question related to the issues in this post.
I've just installed sf() on R 4.3.1, but some of the last lines of the installation output say:
in method for ‘dbWriteTable’ with signature ‘"PostgreSQLConnection","character","sf"’: no definition for class “PostgreSQLConnection”
in method for ‘dbDataType’ with signature ‘"PostgreSQLConnection","sf"’: no definition for class “PostgreSQLConnection”
in method for ‘coerce’ with signature ‘"Spatial","sf"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"Spatial","sfc"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"sf","Spatial"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"sfc","Spatial"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"XY","Spatial"’: no definition for class “Spatial”
in method for ‘coerce’ with signature ‘"crs","CRS"’: no definition for class “CRS”
in method for ‘coerce’ with signature ‘"sgbp","sparseMatrix"’: no definition for class “sparseMatrix”
My question is if those are warnings that something went wrong somewhere. Don't know, but it sounds strange that there are no definitions for class "Spatial" and other classes.
sf() does load, however:
library(sf)
Linking to GEOS 3.10.2, GDAL 3.4.3, PROJ 8.2.0; sf_use_s2() is TRUE
but I'm unsure of whether it is going to work properly or will have problems in the future. I have been using sf() for a while and had not noticed those (potential) warnings before, so perhaps they always show up?
I've seen multiple posts with the same messages for people who had trouble installing sf() [e.g. @McAllister-NOAA's recent question] but decided to ask here precisely because this thread was active very recently. @McAllister-NOAA, did you get those messages/warnings during your recent successful installation of sf()? If so, is sf() behaving normal?
Thanks!
Those are installation messages, nothing to worry about, and completely unrelated to the issue your link to.
Good to know, thanks!