[R-sig-Geo] Errors at installing rgdal on Debian Buster
Agustin Lobo
alobolistas at gmail.com
Fri Sep 15 07:50:45 CEST 2017
I'm now very confused. It seems to me, in line with what you say, that
I had 2 different
kinds of problems:
- Those derived from upgrading from Debian Stretch to Buster (a
consequence of keeping the system as Debian testing: it is just the
consequence of testing passing from Stretch to Buster as
Stretch becomes Stable) and keeping some older versions of different
components (probably installed by packages outside Debian repos). I
guess these problems have been fixed (although I still do not
understand why the rgdal installation claims I have PROJ4.8, which I
cannot find in my system).
- Those derived from Debian packages having been compiled with
different and incompatible options. This is something I cannot fix
myself.
Therefore:
- I will go on compiling myself as Roger suggests to regain an
operational system.
- I will try to test on a fresh Buster system (or a docker, which I
will have to find out what it is...)
- I will report to r-sig-debian and gdal-dev (please suggest an
alternative gdal linst if
gdal-dev is not appropriate).
I'll keep this list informed.
Thanks!
Agus
On Thu, Sep 14, 2017 at 9:26 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
> As Edzer said earlier in this thread (and Agus was quite right to post
> rather than contact me directly), reproducing the problem(s) is hard without
> access to the specific platform (thread started here):
>
> https://stat.ethz.ch/pipermail/r-sig-geo/2017-September/025974.html
>
> My guesses so far are that the gcc build trains used for R, and for the
> GDAL/PROJ.4 components are not the same, and may not be the same as the
> installed gcc build train used to install rgdal from source. This probably
> also affects sf on debian buster (and ubuntu?). It may also affect
> GEOS/rgeos.
>
> The gcc versions do change as platforms are upgraded, so for anything using
> C++, the ABI changes will bite hard, and keeping the compiler versions in
> harmony is crucial. The baseline comparison is to install GDAL and its
> dependencies (including PROJ.4) from source (download and unpack source
> tarball, ./configure && make && make install), then probably R from source,
> finally rgdal. This has to work, but unpicks the debian/ubuntu packaging
> system on which many rely.
>
> Please also consider taking this up on r-sig-debian, with a reproducible
> example, best in a docker container.
>
> A further thought is that the most frequent cause of trouble on
> debian/ubuntu previously were multiple installs of different versions of
> GDAL, pulled in by different downstream packages, but the current reports do
> not suggest this as the cause. Still worth checking, though ...
>
> Roger
>
>
> On Wed, 13 Sep 2017, Roger Bivand wrote:
>
>> On Wed, 13 Sep 2017, Agustin Lobo wrote:
>>
>>> The problem seems to be related to the compiler. I had:
>>> gcc version 5.3.1 20160101 (Debian 5.3.1-5)
>>>
>>> I have now:
>>> gcc version 7.2.0 (Debian 7.2.0-4)
>>>
>>> All weird previus errors are gone but I still have:
>>> configure: PROJ.4 version: 4.8.0
>>> ./configure: line 3725: 8390 Segmentation fault ./proj_conf_test
>>> checking PROJ.4: epsg found and readable... yes
>>> ./configure: line 3800: 8399 Segmentation fault ./proj_conf_test
>>>
>>> and finally
>>>
>>> ** testing if installed package can be loaded
>>> Fatal error: glibc detected an invalid stdio handle
>>> Aborted
>>> ERROR: loading failed
>>> * removing ‘/home/alobo/R/i686-pc-linux-gnu-library/3.3/rgdal’
>>>
>>> Surprisingly, I do have 4.9 installed, not 4.8:
>>>
>>> $ dpkg -s proj-bin
>>> Package: proj-bin
>>> Status: install ok installed
>>> Priority: optional
>>> Section: science
>>> Installed-Size: 125
>>> Maintainer: Debian GIS Project <pkg-grass-devel at lists.alioth.debian.org>
>>> Architecture: i386
>>> Source: proj
>>> Version: 4.9.3-2
>>>
>>> and
>>> $ proj
>>> Rel. 4.9.3, 15 August 2016
>>> usage: proj [ -bCeEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ]
>>>
>>> and I cannot find proj_conf_test anywhere:
>>> $ sudo find / -name 'proj_conf_test'
>>> gives no result
>>>
>>> How is the test ./proj_conf_test done so that I can investigate why it
>>> results into PROJ 4.8 instead of 4.9?
>>
>>
>> It is defined in rgdal/configure.ac (line 273 ff.):
>>
>> if test ${proj_version} -ge 480; then
>> [cat > proj_conf_test.c <<_EOCONF
>> #include <stdio.h>
>> #include <proj_api.h>
>> #if PJ_VERSION == 480
>> FILE *pj_open_lib(projCtx, const char *, const char *);
>> #endif
>>
>> int main() {
>> #if PJ_VERSION <= 480
>> FILE *fp;
>> #else
>> PAFile fp;
>> #endif
>> projCtx ctx;
>> ctx = pj_get_default_ctx();
>> fp = pj_open_lib(ctx, "epsg", "rb");
>> if (fp == NULL) exit(1);
>> #if PJ_VERSION <= 480
>> fclose(fp);
>> #else
>> pj_ctx_fclose(ctx, fp);
>> #endif
>> exit(0);
>> }
>> _EOCONF]
>> else
>> [cat > proj_conf_test.c <<_EOCONF
>> #include <stdio.h>
>> #include <proj_api.h>
>> FILE *pj_open_lib(const char *, const char *);
>>
>> int main() {
>> FILE *fp;
>> fp = pj_open_lib("epsg", "rb");
>> if (fp == NULL) exit(1);
>> fclose(fp);
>> exit(0);
>> }
>> _EOCONF]
>> fi
>>
>> and checks that the crucial epsg file is present. It does seem to run,
>> though, which is puzzling - if you read configure.ac, you'll see that I
>> didn't guard against the previous (different) ./proj_conf_test already
>> existing - I'll revise the test names to avoid such false positives in the
>> future.
>>
>> Roger
>>
>>>
>>> Thanks
>>>
>>> Agus
>>>
>>>
>>>
>>> On Tue, Sep 12, 2017 at 1:49 PM, Roger Bivand <Roger.Bivand at nhh.no>
>>> wrote:
>>>>
>>>> $ g++ -v
>>>> ...
>>>> gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC)
>>>>
>>>> in my case on Fedora 26.
>>>>
>>>> Recent versions should be OK, but < 5 may be problematic. If you have
>>>> upgraded in place but not upgraded the compile trains, installing r-base
>>>> will not force that.
>>>>
>>>>
>>>>
>>>
>>
>>
>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
> Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
> http://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
More information about the R-sig-Geo
mailing list