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 >> [email protected] >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > _______________________________________________ > R-SIG-Mac mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
