[R-sig-Geo] Errors at installing rgdal on Debian Buster

Fri Sep 15 09:32:35 CEST 2017

On Fri, 15 Sep 2017, Agustin Lobo wrote:

> 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).

Please see whether there are multiple proj_api.h files on your system - if 
so, rgdal is picking up the first in your search path, but may link 
against a later *.so, explaining the crashes during the configure run.

> - 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...)

https://github.com/rocker-org/rocker
http://dirk.eddelbuettel.com/papers/useR2015_docker.pdf

for example.

> - I will report to r-sig-debian and gdal-dev (please suggest an
> alternative gdal linst if
> gdal-dev is not appropriate).
>

(please keep your heads covered as GEOS and GDAL transition to requiring 
>= C++11 ...) Yes, at this stage sharing information is valuable so that 
others can learn from hard-won experience.

Roger

> 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
>

-- 
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