Errors at installing rgdal on Debian Buster

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

= C++11 ...) Yes, at this stage sharing information is valuable so that 

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