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

[Roger Bivand]

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