-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating sf
from 1.0.3 to 1.0.4 fails under PROJ 8.1.1-GEOS 3.9.0-GDAL 3.2.2-R 4.1.2-Debian 11
#1850
Comments
See https://github.com/r-spatial/sf#multiple-gdal-geos-andor-proj-versions-on-your-system You most likely have multiple versions installed from PROJ, GEOS and/or GDAL. |
@edzer I believe I have a unique version from each library:
Let me know if I should do another check. |
It looks as though you use the OS packaging system for installing external software. Is this related to r-spatial/spatialreg#22 and specifically r-spatial/spatialreg#22 (comment), so maybe back out of |
@rsbivand Thanks,
It seems a related issue indeed. Thanks for pointing me to it.
Yes, I try to use
I will check this, so maybe having all these packages installed from |
sf
from 1.0.3 to 1.0.4 failssf
from 1.0.3 to 1.0.4 fails under PROJ 8.1.1, GEOS 3.9.0, GDAL 3.2.2, R 4.1.2, Debian 11
sf
from 1.0.3 to 1.0.4 fails under PROJ 8.1.1, GEOS 3.9.0, GDAL 3.2.2, R 4.1.2, Debian 11sf
from 1.0.3 to 1.0.4 fails under PROJ 8.1.1-GEOS 3.9.0-GDAL 3.2.2-R 4.1.2-Debian 11
Please try and report back.My own current experience in upgrading Fedora 34 to 35 has been that although compilers and basic libraries were the same versions (F34 was fully updated), I had to rebuild my source installed PROJ/GEOS/GDAL because libnetcdf on which GDAL depends had changed version between F34 and F35. So second or third degree dependencies somewhere in the dependency tree can be a problem. Of cource I re-install R anyway from source, but that is just normal caution. |
I have checked the 3 libraries for PROJ/GEOS/GDAL are installed from
|
With the same PROJ/GEOS/GDAL, try to install terra and rgdal. If they (and say vapour) all fail at the same point, @edzer 's suspicion that you have multiple installs lurking on your system would be strengthened. Crucially, some other package may draw in a different version of GDAL with just the dynamic libraries, but these on loading come ahead of the GDAL used for building. If the installs of the other R packages do not fail, there may be someting in the packaging of the specific versions for your target platform, and I'd bring in people who know about your platform. |
Similar happens with
and with
I did not try with I only installed these packages using |
I think we diagnosed your problem, but have to leave solving it up to you. |
Installs for Python could very well be the reason. Maybe try on a completely separate bare machine, installing each component separately in sequence. Trying to get Python to use my PROJ/GEOS/GDAL is painful and difficult, as the level of predictive package coordination is simply not comparable to R. So maybe either Python stuff in its container, and R in the system, the reverse, or both in their own containers? |
Thanks both for the help. I will check the issue #844 carefully and against the above outputs trying to install these packages . |
Finally I reinstalled stable versions of PROJ, GEOS and GDAL and I could update both Considering what @rsbivand commented, my hypothesis for all this is that when installing |
All seems fine until
Under
Let me know if I can give more information.
I should add that I am working on Debian 11, but I have installed
proj-bin
8.1.1-1 fromtesting
distribution. May it be related to the issue?The text was updated successfully, but these errors were encountered: