configure: error: libproj or sqlite3 not found in standard or given locations. #1471
Comments
|
The error you see is frequently seen when certain libraries on your system are installed at more than one place in different versions (e.g. packaged, as well as from source), see here. |
|
Thank you for the reply. I tried installing again using the --with-proj-lib flag and with --with-proj-include flags but got the same error. I find the message confusing because even though it says "libproj or sqlite3 not found in standard or given locations." I've found nothing in the documentation or configure files that let's specify the location of sqlite3. Is there an option to specify the location of the sqlite3 libraries? I've verified that the proj lib is linked to my sqlite3 install. And, I compiled sf.so again with my hacked configure script without letting R test loading it. The resulting sf.so is linked to the proper proj and sqlite3 libs. [wa02042@mforgehn4 R]$ ldd /usr/local/biotools/rpackages/R-3.6.2-latest/sf/libs/sf.so | grep proj This is not a standard Fedora box. It's a research node for the Mayo Clinic on which I don't have root access and can't use apt-get so I've compiled everything from source. Any further insight would be greatly appreciated. |
|
I think the way forward is to stop breaking ./configure when this test breaks, maybe only giving a message that the test fails. It requires libsqlite3-dev, but that is not required if PROJ and GDAL were installed as binary packages. |
|
I am having a similar problem Is it possible to use a flag like --with-sqlite3-lib? like with proj? For reference here is what I tried |
|
Feel free to submit a PR - I see this is a problem, someone has to solve it. |
|
Hi, Anyway i managed this issue using environment vauables: LIBS, LDFLAGS, CPPFLAGS anc CFLAGS to specify non standard paths for the compiler. Kind Regards |
|
Hi What is the solution to this ? What env variables are you using for sql lite ? LD_LIBRARY_PATH This is my error checking gdal.h usability... yes removing ���/mnt/opt/Centos7/hpc/spack/spack_Oct_2020/opt/spack/linux-centos7-broadwell/gcc-7.3.1/r-4.0.3-tu34p762h7igt6pdf7wlfm4fnaxmxyne/rlib/R/library/sf��� |
|
I'm loading environment modules (lmod) within our ldpaths file within the R install to load sqlite and proj modules, both prepending PATH, CPATH, LD_LIBRARY_PATH, and PKG_CONFIG_PATH |
|
Hi Jeff, Thanks for your answer I used to work at Lilly too some years ago ! I am using standard Linux environment modules ie module load ... the only variable you have listed above I am missing is CPATH. but no still luck ! cheers |
|
Are you also loading the gdal module and can you confirm that both gdal and proj were compiled with the sqlite version you're using? For proj, I'm using 7.2.0, but I forget the minimum version needed. |
|
Fixed it, my GEOS module was not the one referenced in my GDAL module. The Error message was completely unrelated unfortunately. Thanks for your help jeff as mentioning GDAL made me start looking along the rest of the chain. |
|
I have a similar problem. I'm thinking it is because I'm on the cluster and load the module for dgal, proj and geos sperately. there is no version problems, but I got the same error with @serbinsh
how shall I identify the directory for those modules and sqlite? |
I have the same issue. Have you succeeded? How did you find these directories? |
@rrobinson-RMS Hi Robinson, how did you solve your problem. I have the same issue with you. I'm on cluster too. |
|
I'm facing the same issue so I'm re-posting on this thread as it doesn't seem to have been resolved yet. I'm running R 4.0.3 on a cluster and load gdal (3.2.0), geos (3.8.1), proj (7.1.0) and sqlite (3.33.0) modules before launching R and trying to install sf package. I get the same error as @ice4prince @rrobinson-RMS and others reported:
The downloaded source packages are in Does anyone know how to solve this issue? |
|
I have the same issue: Session info Back in the terminal I've got |
the development libraries of sqlite3 are needed, not the executable. In general, this is some kind of conda install, and I have no clue what is going on there. |
|
After much tedious trial and error, I think I may have a solution for those still running into this error. Two steps are necessary:
I am using proj v8.1.1, sqlite3 v3.33.0 and gdal-config v3.3.2. When compiling proj, add Then I got the following output: P.S. Using gdal v2.3.2 has the |
|
Another note for anyone still experiencing issues. Check ldd for the gdal libraries after compilation. While testing we had no trouble, but in production, gdal would add system library paths to the rpath overriding the custom path to sqlite3 libraries (which it also correctly had, but later in the rpath string). This caused everything down the chain to fail. |
|
Very very strangely, coming back to this, I was able to get the compilation to work with yet even with the warming "configure: WARNING: unrecognized options: --with-proj but when i try just I get the original error I posted earlier above??? |
Same problem on macOS 12.
|
|
@mys721tx please see section: "Installing packages linking to PROJ, GDAL or GEOS" on https://cran.r-project.org/view=Spatial. Unless you meet those criteria for a source install, use binary installs. If you do meet them, you will yourself understand that upstream external dependencies must be met first. |
|
@rsbivand Please see the printout for pkg-config in the bottom. The external dependencies are installed. |
|
@mys721tx do you need to install from source? If not, install sf binary from CRAN. Otherwise you have to figure out yourself how to pass correct configure arguments to |
|
Yes, for my particular setup the binary package does not work since the homebrew . I did some digging and it turned out that Homebrew's I will work on a PR and hopefully it will fix the problem on macOS. |
|
Why can you not simply install sf binay and then other packages as you wish? Does the specific version of GDAL, PROJ or GEOS matter for your use case? There is no point creating any homebrew PR, homebrew is not a CRAN-supported installation approach. |
|
There is a more fundamental problem at hand. The error message |
|
Homebrew is advised against across R-macOS because of the present danger of mixing build train components (slightly different versions of compilers and linkers, leading to unreproducible errors. CRAN binary packages are built static to ensure that everyone is seeing the same software. All should use CRAN binaries only, unless they are package developers, and these should use the static binary upstream libraries built using the same clang/clang++ versions used for the software into which packages are being dynamically loaded. It may be that your PR to |
|
If you are on apple silicon (M series) processor and also used homebrew to install the library, try use this command, it worked for me. updated on 2023-04-24 For package sf install.packages('sf', configure.args = configure.args = '--with-gdal-config=/opt/homebrew/bin/gdal-config --with-geos-config=/opt/homebrew/Cellar/geos/3.11.2/bin/geos-config --with-proj-include=/opt/homebrew/Cellar/proj/9.2.0/include --with-proj-lib=/opt/homebrew/Cellar/proj/9.2.0/lib', configure.vars = 'GDAL_DATA=/opt/homebrew/opt/gdal/share/gdal/')Also for package terra install.packages('terra', configure.args = '--with-gdal-config=/opt/homebrew/bin/gdal-config --with-geos-config=/opt/homebrew/Cellar/geos/3.11.2/bin/geos-config --with-proj-include=/opt/homebrew/Cellar/proj/9.2.0/include --with-proj-lib=/opt/homebrew/Cellar/proj/9.2.0/lib', configure.vars = 'GDAL_DATA=/opt/homebrew/opt/gdal/share/gdal/') |
|
I'm encountering the same issue. I can use the binary, of course. But I would like to modify the source code to make a PR. This cannot be done without being able to run the package locally. R CMD build and proj and sqlite have been installed via homebrew and are available. Is there other documentation that I can refer to? |
|
If using macOS, please follow https://cran.r-project.org/view=Spatial, final section. Avoid homebrew, use CRAN-built external software binaries from https://mac.r-project.org/tools/. If homebrew, no support is offered. It is important to use the same build tools as R itself. |
|
I'm sorry, I do not follow that section of the documentaiton. I have the CRAN supplied fortran compiler installed and xcode installed as well. Installation of gdal was done per https://github.com/r-spatial/sf#macos. Further installation of proj was done per #1536 (comment) in the same section installing from source. If there is some nuance between the lines in the CRAN view it is unfortunately lost on me. |
|
Do not follow the readme, in my opinion none of the maintainers have access to or use homebrew. Unless you must build GDAL etc. yourself, use the proper CRAN-built binaries. If you must build yourself, use the CRAN upstream binaries to build static, not dynamic. Note that some xcode and macOS break build instructions. Which OS version, which architecture? Which R version? |
|
Hah, okay! Good to know. I've removed proj, and gdal homebrew install. Per comment at #1848 (comment) it might be best to download and copy from https://mac.r-project.org/bin/darwin20/arm64/. Though it's unclear how exactly. Re OS arch and version |
|
on centos7, I took the following approach to solve this problem:
|
I maintain ~1200 install and maintain R packages on a RHEL7 for which I don't have root access. I've found the best approach is to install all compiled libraries to support R packages in one place. I need to install sf as a dependency for other packages. I've successfully installed gdal, proj7, tiff-4, and geos. I've also installed a newer version of sqlite3 than what was on our system because one of these packages required it (proj7 I believe).
When I got the configure error "libproj or sqlite3 not found in standard or given locations," I initially thought it was because sqlite3 was not in a standard location because the sf config files don't use pkg-config for sqlite3 (although pkg-config is used for proj). However, when I execute the test on the command on the command line, I get the same error whether my PATH is pointing to the default sqlite3 install or mine. So, now I'm not sure if it's a sqlite3 issue at all.
[wa02042@mforgehn5 sf]$ ${CXX} ${CPPFLAGS} -o proj_conf_test proj_conf_test.cpp ${LIBS} -lsqlite3
/tmp/ccuBYW9n.o: In function
main': proj_conf_test.cpp:(.text+0x5): undefined reference toproj_context_create'collect2: error: ld returned 1 exit status
[wa02042@mforgehn5 sf]$ which sqlite3
/bin/sqlite3
[wa02042@mforgehn5 sf]$ sqlite3 --version
3.7.17 2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668
[wa02042@mforgehn4 sf]$ g++ -std=gnu++11 -I/usr/local/biotools/r/R-3.6.2/R-dependencies/include -o proj_conf_test proj_conf_test.cpp -lsqlite3
/tmp/ccnTaFWO.o: In function
main': proj_conf_test.cpp:(.text+0x5): undefined reference toproj_context_create'collect2: error: ld returned 1 exit status
[wa02042@mforgehn4 sf]$ rpm -E %{rhel}
7
[wa02042@mforgehn4 sf]$ which sqlite3
/usr/local/biotools/ver2/2.0.0/bin/sqlite3
[wa02042@mforgehn4 sf]$ sqlite3 --version
3.33.0 2020-08-14 13:23:32 fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f
[wa02042@mforgehn4 sf]$ which g++
/usr/local/scl/devtoolset-8/root/usr/bin/g++
[wa02042@mforgehn4 sf]$ g++ --version
g++ (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I read through the other sqlite3 post where someone questioned if the -sqlite3 flag is necessary at all. I tried hacking the configure.ac file to skip over the test. I was able to get the shared library to compile, but there's a segfault when I try to load it into R.
[wa02042@mforgehn4 R]$ R --vanilla CMD INSTALL -l /usr/local/biotools/rpackages/R-3.6.2-latest sf
files �configure�, �configure.ac� have the wrong MD5 checksums
** using staged installation
configure: CC: gcc
configure: CXX: g++ -std=gnu++11
checking for gdal-config... /usr/local/biotools/ver2/2.0.0/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 3.1.2
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 we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... 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... no
checking GDAL: linking with --libs and --dep-libs... yes
checking GDAL: /usr/local/biotools/ver2/2.0.0/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.1.2
configure: pkg-config proj exists, will use it
configure: using proj.h.
configure: PROJ: 7.1.0
checking PROJ: checking whether PROJ and sqlite3 are available for linking:... no
checking for geos-config... /usr/local/biotools/ver2/2.0.0/bin/geos-config
checking geos-config usability... yes
configure: GEOS: 3.8.1
checking GEOS version >= 3.4.0... yes
checking geos_c.h usability... yes
checking geos_c.h presence... yes
checking for geos_c.h... yes
checking geos: linking with -L/usr/local/biotools/ver2/2.0.0/lib -lgeos_c... yes
configure: Package CPP flags: -I/usr/local/biotools/ver2/2.0.0/include -DHAVE_PROJ_H -I/usr/local/biotools/ver2/2.0.0/include -I/usr/local/biotools/ver2/2.0.0/include
configure: Package LIBS: -L/usr/local/biotools/ver2/2.0.0/lib -lproj -L/usr/local/biotools/ver2/2.0.0/lib -lgdal -lcrypto -lsqlite3 -lexpat -ljpeg -ltiff -lpng -L/usr/local/biotools/ver2/2.0.0/lib -lproj -lsqlite3 -lz -lpthread -lm -lrt -ldl -lpcre -lcurl -lxml2 -L/usr/local/biotools/ver2/2.0.0/lib -lgeos_c
configure: creating ./config.status
config.status: creating src/Makevars
** libs
make: Nothing to be done for 'all'.
installing to /usr/local/biotools/rpackages/R-3.6.2-latest/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�
** help
*** installing help indices
*** copying figures
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
sh: line 1: 11870 Segmentation fault '/usr/local/biotools/r/R-3.6.2/lib64/R/bin/R' --no-save --slave 2>&1 < '/tmp/RtmpBAXIVh/filed0442428581'
*** caught segfault ***
address 0x89156, cause 'memory not mapped'
Traceback:
1: dyn.load(file, DLLpath = DLLpath, ...)
2: library.dynam(lib, package, package.lib)
3: loadNamespace(package, lib.loc)
4: doTryCatch(return(expr), name, parentenv, handler)
5: tryCatchOne(expr, names, parentenv, handlers[[1L]])
6: tryCatchList(expr, classes, parentenv, handlers)
7: tryCatch({ attr(package, "LibPath") <- which.lib.loc ns <- loadNamespace(package, lib.loc) env <- attachNamespace(ns, pos = pos, deps, exclude, include.only)}, error = function(e) { P <- if (!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L]) else "" msg <- gettextf("package or namespace load failed for %s%s:\n %s", sQuote(package), P, conditionMessage(e)) if (logical.return) message(paste("Error:", msg), domain = NA) else stop(msg, call. = FALSE, domain = NA)})
8: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return = TRUE)
9: withCallingHandlers(expr, packageStartupMessage = function(c) invokeRestart("muffleMessage"))
10: suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return = TRUE))
11: doTryCatch(return(expr), name, parentenv, handler)
12: tryCatchOne(expr, names, parentenv, handlers[[1L]])
13: tryCatchList(expr, classes, parentenv, handlers)
14: tryCatch(expr, error = function(e) { call <- conditionCall(e) if (!is.null(call)) { if (identical(call[[1L]], quote(doTryCatch))) call <- sys.call(-4L) dcall <- deparse(call)[1L] prefix <- paste("Error in", dcall, ": ") LONG <- 75L sm <- strsplit(conditionMessage(e), "\n")[[1L]] w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w") if (is.na(w)) w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L], type = "b") if (w > LONG) prefix <- paste0(prefix, "\n ") } else prefix <- "Error : " msg <- paste0(prefix, conditionMessage(e), "\n") .Internal(seterrmessage(msg[1L])) if (!silent && isTRUE(getOption("show.error.messages"))) { cat(msg, file = outFile) .Internal(printDeferredWarnings()) } invisible(structure(msg, class = "try-error", condition = e))})
15: try(suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return = TRUE)))
16: tools:::.test_load_package("sf", "/usr/local/biotools/rpackages/R-3.6.2-latest/00LOCK-sf/00new")
An irrecoverable exception occurred. R is aborting now ...
ERROR: loading failed
Any feedback you could give me here would be greatly appreciated. Thank you.
The text was updated successfully, but these errors were encountered: