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

Fri Sep 15 09:16:24 CEST 2017

Forwarded to list, as Xavier is not subscribed.

Roger

On Thu, 14 Sep 2017, Xavier Prudent wrote:

> Dear all,
>
> I had to recreate the /etc/source.list
> and could then install homebrew and hence gdal, hence rgdal,
>
> that was quite a ride :) but it worked!
>
> Thank you for your help!
>
> Greetings,
>
> Xavier Prudent
>
> 2017-09-14 3:26 GMT-04:00 Roger Bivand <Roger.Bivand at nhh.no>:
>
>> 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)
>>>>> <https://maps.google.com/?q=.1.1-3)+(GCC)&entry=gmail&source=g>
>>>>>
>>>>> 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
>
>
>
>
>

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