[STATSGRASS] Re: [R] Problems installing GRASS package

[Roger Bivand]

On Thu, 28 Oct 2004, Prof Brian Ripley wrote:

> On Thu, 28 Oct 2004, Roger Bivand wrote:
> 
> > (Transferred from R-help: does anyone have a working R-GRASS interface on 
> > Free-BSD? - see further down for Paul English's compile problem (replies 
> > please also directly to Paul who is almost certainly not subscribed):)
> > 
> > On Thu, 28 Oct 2004, Prof Brian Ripley wrote:
> > 
> > > Please send such problems, with solution, to the package maintainers.
> > > 
> > > They do not occur generally and seem to be due to the system headers on 
> > > your particular system.  Only users of `FreeBSd' will be able to 
> > > troubleshoot, i.e. you.
> > 
> > I am willing to try to help with this - it is an unusual case and the 
> > first reported - there is a mailing list from the GRASS side where there 
> > may be more experience:
> > 
> > http://grass.itc.it/mailman/listinfo/statsgrass
> > 
> > > 
> > > In this particular case, I think the package needs to use its own headers
> > > only if the system ones are not available (via a configure test), and
> > > suggest you try deleting GRASS/src/include/rpc.  (Roger: the zlib.h and
> > > zconf.h are also worrying, as they might mismatch the libz used.)
> > > 
> > 
> > This is a very valid concern, and one that the GRASS transition from 5.0.*
> > stable to 5.4.* stable due in the near future will make relevant - the
> > current included GRASS code is directly copied from 5.0.*. It is very
> > likely that the GRASS package (the R-GRASS interface) will return to
> > linking against external libraries rather than contain a local (aging)
> > copy of the GRASS library source code, and it is this that links to zlib
> > and the XDR headers. I am obliged to balance these concerns with what
> > GRASS users with production systems find necessary; when the code looks
> > ugly, I'm afraid there were practical reasons for the choices. I'll try to
> > get things in better shape for GRASS 5.4.* and its successor GRASS 5.7.*.
> 
> I'm sorry, but that is not what is happening here.  The GRASS package is
> not linked against anything other than R and so the xdr functions used are
> found from the OS library (usually libc), or from R.dll on Windows.  So
> you do need the headers from the OS, if it has them, otherwise those from
> the R sources.  In practice I suspect all platforms R runs on have xdr
> other than Windows.  Concrete evidence:
> 
> gannet% nm -pg GRASS.so | grep xdr
>          U xdrmem_create@@GLIBC_2.0
>          U xdr_double@@GLIBC_2.0
>          U xdr_float@@GLIBC_2.0
> 
> My suggestion to delete the rpc/xdr headers is likely to work everywhere 
> but on Windows.
> 
> As for zlib, 
> 
> gannet% nm -pg GRASS.so | grep flate
>          U deflate
>          U inflate
>          U inflateInit_
>          U deflateInit_
>          U inflateEnd
>          U deflateEnd
> 
> so you are linking against the libz in R and you *do* have version
> mismatch, of a 1.1.4 header used with libz 1.2.1 (which is what R
> contains).  Fortunately that is unlikely to be a problem.

Thank you for these specific points. I will look at providing a 
Makevars.win with the additional includes in a place hidden from 
non-Windows builds as a start. The package initially had a configure 
script, but this was a cause of difficulty for Windows installs, and led 
to the change from linking to GRASS libraries externally to having local 
copies.

> 
> With an external GRASS library there is even more room for mismatches.
> 
This is also valid, because I'm not sure that GRASS builds leave a trail 
of which libraries they have linked against themselves in a discoverable 
form. I can take this up with GRASS developers - it will be in the GRASS 
config.log, but may not be available when binaries are distributed.

My main worry now is how to make things better without interrupting 
on-going research - Markus, do you have any ideas? Can we extract in a 
reliable way what a GRASS build depends on and list it portably do that 
thr R-GRASS interface can use it when it builds? Have you seen any signs 
of failure because of version mismatch (unfortunately, not seeing it 
doesn't mean it hasn't happened)? The compression library is crucial for 
raster layer storage.

Roger

> 
> Brian
> 
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no