Exactly. I did not investigate mutch... but I'm interested to know if there is a workaround.
Regards, 2012/4/22 Justin Deoliveira <[email protected]>: > Hi Francesco, > > Thanks for confirming, this is exactly what I get as well. > > Registered library as gdal > Invalid memory access of location 0x13d36cb74 rip=0x103165210 > /bin/sh: line 1: 55016 Segmentation fault: 11 > > Seems the library loads ok but the first call into ogr segfaults. > > -Justin > > On Sun, Apr 22, 2012 at 6:10 AM, Francesco Izzi <[email protected]> > wrote: >> >> Hello Justin >> >> some time ago I tried it on OSX Lion but the tests failed: >> >> ------------------------------------------------------- >> T E S T S >> ------------------------------------------------------- >> Running org.geotools.data.ogr.GeometryMapperTest >> Registered library as gdal >> Invalid memory access of location 0x13d36cb74 rip=0x103165210 >> /bin/sh: line 1: 55016 Segmentation fault: 11 >> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java >> -Xmx512M -Dorg.geotools.test.extensive=false >> -Dorg.geotools.test.interactive=false >> -Dorg.geotools.image.test.enabled=true >> -Dorg.geotools.image.test.interactive=false >> '-Djava.awt.headless=${java.awt.headless}' >> -Djava.io.tmpdir=/var/folders/cs/551x1_nd5xl142_qrs22h5980000gn/T/ >> -jar >> /Users/fizzi/sviluppo/codice/geosdi/gt-trunk/modules/unsupported/ogr/target/surefire/surefirebooter301142255284689358.jar >> >> /Users/fizzi/sviluppo/codice/geosdi/gt-trunk/modules/unsupported/ogr/target/surefire/surefire3539506481835657568tmp >> >> /Users/fizzi/sviluppo/codice/geosdi/gt-trunk/modules/unsupported/ogr/target/surefire/surefire8826194368430222431tmp >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD FAILURE >> [INFO] >> ------------------------------------------------------------------------ >> >> We can do other tests ...in order to understand where the problem, >> >> Regards, >> >> 2012/4/22 Justin Deoliveira <[email protected]>: >> > Hey Andrea, >> > >> > I have been continuing to look at the ogr datastore recently. >> > Unfortunately >> > despite my best efforts I still can't figure why it won't work for me on >> > osx. It would be nice if another osx developer could confirm to rule out >> > anything specific to my environment. I have also reached out to the >> > bridj >> > user list but have yet to hear anything back yet. >> > >> > That said, it got me thinking. What about supporting both interfaces? >> > Basically the idea is to come up with an adapter interface, and then >> > implement it based on bridj/jna and then another implementation based on >> > the >> > jni interface and existing ogr java api. I played around a bit today and >> > here is what i came up with, posted to my github repo. >> > >> > https://github.com/jdeolive/geotools/tree/ogr >> > >> > The adapter interface. >> > >> > >> > >> > https://github.com/jdeolive/geotools/blob/ogr/modules/unsupported/ogr/src/main/java/org/geotools/data/ogr/OGR.java >> > >> > And the bridj implementation: >> > >> > >> > >> > https://github.com/jdeolive/geotools/blob/ogr/modules/unsupported/ogr/src/main/java/org/geotools/data/ogr/bridj/BridjOGR.java >> > >> > All the existing classes are now written against the interface, with the >> > concrete implementation being provided by a specific data astore >> > factory: >> > >> > >> > >> > https://github.com/jdeolive/geotools/blob/ogr/modules/unsupported/ogr/src/main/java/org/geotools/data/ogr/bridj/BridjOGRDataStoreFactory.java >> > >> > All tests pass. This was in part an exercise to get aquatinted with the >> > ogr >> > java api and with bridj. But I think this could be a decent way forward, >> > especially if it turns out that bridj does have issues on some >> > platforms. >> > >> > What do you think? >> > >> > -Justin >> > >> > -- >> > Justin Deoliveira >> > OpenGeo - http://opengeo.org >> > Enterprise support for open source geospatial. >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > For Developers, A Lot Can Happen In A Second. >> > Boundary is the first to Know...and Tell You. >> > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> > http://p.sf.net/sfu/Boundary-d2dvs2 >> > _______________________________________________ >> > GeoTools-Devel mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > >> >> >> >> -- >> Francesco Izzi >> CNR - IMAA >> geoSDI >> Direzione Tecnologie e Sviluppo >> >> C.da S. Loja >> 85050 Tito Scalo - POTENZA (PZ) >> Italia >> >> phone: +39 0971427305 >> fax: +39 0971 427271 >> mob: +39 3203126609 >> mail: [email protected] >> skype: neofx8080 >> >> web: http://www.geosdi.org > > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > -- Francesco Izzi CNR - IMAA geoSDI Direzione Tecnologie e Sviluppo C.da S. Loja 85050 Tito Scalo - POTENZA (PZ) Italia phone: +39 0971427305 fax: +39 0971 427271 mob: +39 3203126609 mail: [email protected] skype: neofx8080 web: http://www.geosdi.org ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
