[prev in list] [next in list] [prev in thread] [next in thread] 

List:       r-sig-mac
Subject:    Re: [R-SIG-Mac] R 3.0, rgdal, and the oft unloved Mac OS
From:       Simon Urbanek <simon.urbanek () r-project ! org>
Date:       2013-04-11 15:13:38
Message-ID: DAA6380A-E965-49CC-84DB-DDFE72DCB679 () r-project ! org
[Download RAW message or body]

It seems that gdal gets confused with internal and external libraries in a static \
build - likely causing API mismatch which demonstrated itself in the crash. After \
re-building gdal with minimal dependencies it seems to work. The rgdal binary is up.

Cheers,
Simon


On Apr 11, 2013, at 9:55 AM, Simon Urbanek wrote:

> On Apr 10, 2013, at 3:26 PM, Ian Fellows wrote:
> 
> > On a related note to the lme4 query∑ There was a glorious period of time where \
> > rgdal binaries (with it's external dependancies) were available on CRAN for the \
> > mac. Unfortunately, with the introduction of R 3.0 this is no longer the case. It \
> > now requires a rather protracted install process (installing GDAL, then PROJ4, \
> > then installing rgdal from source using the proper configuration arguments). I \
> > understand that this is a known issue \
> > https://stat.ethz.ch/pipermail/r-sig-geo/2013-April/017989.html, and was \
> > wondering whether CRAN is planning on supporting a binary distribution in the \
> > future. If not, is CRAN Extras planning on hosting it? 
> 
> rgdal fails the checks, it segfaults:
> http://www.R-project.org/nosvn/R.check/r-release-macosx-x86_64/rgdal-00check.html
> 
> Here is the output of valgrind:
> 
> > logo <- system.file("pictures/logo.jpg", package="rgdal")[1]
> > x <- new("GDALReadOnlyDataset", logo)
> ==41210== Syscall param sigprocmask(set) points to uninitialised byte(s)
> ==41210==    at 0x41D0FA: sigprocmask (in /usr/lib/libSystem.B.dylib)
> ==41210==    by 0x75756E1: jpeg_CreateDecompress (jdapimin.c:38)
> ==41210==    by 0x6FBFAA1: JPGDataset::Open(GDALOpenInfo*) (jpgdataset.cpp:1833)
> ==41210==    by 0x70EF3F5: GDALOpenInternal(GDALOpenInfo&, char const* const*) \
> (gdaldataset.cpp:2236) ==41210==    by 0x70EF5C0: GDALOpenInternal(char const*, \
> GDALAccess, char const* const*) (gdaldataset.cpp:2208) ==41210==    by 0x6E731A0: \
> RGDAL_OpenDataset (gdal-bindings.cpp:574) ==41210==    by 0x89032: do_dotcall \
> (dotcode.c:585) ==41210==    by 0xB1D66: Rf_eval (eval.c:612)
> ==41210==    by 0xBFACF: do_begin (eval.c:1534)
> ==41210==    by 0xB1BD5: Rf_eval (eval.c:584)
> ==41210==    by 0xBED3C: applydefine (eval.c:1689)
> ==41210==    by 0xB1BD5: Rf_eval (eval.c:584)
> ==41210==  Address 0x7fff5fbfb870 is on thread 1's stack
> ==41210== 
> --41210:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
> ==41210== Warning: client switching stacks?  SP change: 0x7fff5fbfb888 --> \
> 0x100207c48 ==41210==          to suppress, use: --max-stackframe=140730502691904 \
> or greater ==41210== Conditional jump or move depends on uninitialised value(s)
> ==41210==    at 0x41D1A9: _longjmp (in /usr/lib/libSystem.B.dylib)
> ==41210==    by 0x1000BBDC7: ???
> ==41210==    by 0x100207C17: ???
> ==41210==    by 0x100F6C7E7: ???
> ==41210== 
> 
> .. followed by a crash. Possibly some incompatibility between jpeg and gdal? I may \
> have a look later unless the maintainers have some insight... 
> Cheers,
> Simon
> 
> 
> > I'm currently in the process of updating the OpenStreetMap package, and was \
> > planning on moving rgdal from a suggest to a depends, but would like to know the \
> > lay of the land before proceeding. 
> > Best,
> > Ian
> > 	[[alternative HTML version deleted]]
> > 
> > _______________________________________________
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


[prev in list] [next in list] [prev in thread] [next in thread]