[gdal-dev] Autotest/Driver Registration Help

Wed Nov 6 11:41:47 PST 2013

It does, though 'otool -L' indicates it's reading libgdal from /usr/local/lib, in defiance of DYLD_LIBRARY_PATH. Fortunately I installed there previously so I guess that's why it's finding the driver. Installing hasn't changed the behaviour of the python test though.

  -> "GPKG" (read/write)

P.

--  
Paul Ramsey | Boundless
http://boundlessgeo.com/support/postgis
2508850632 | @pwramsey
> >  
> >  
> >  
>  
>  
>  

On Wednesday, November 6, 2013 at 11:38 AM, Even Rouault wrote:

> Le mercredi 06 novembre 2013 20:35:46, Paul Ramsey a écrit :
> > Completely getting nothing... even when I install gdal into /usr/local/lib
> > over top of my standard gdal, the basic driver registration stubbornly
> > returns 'None'
> >  
> > gpkg_dr = ogr.GetDriverByName( 'GPKG' )
> >  
> > It makes me think I'm doing something wrong in adding the driver to OGR,
> > but I've gone over it many many times, comparing to cartodb and sqlite and
> > it's doing all the things it should do. It's being detected, it's
> > building, I can run 'nm' on libgdal and see all the class names and even
> > the _RegisterOGRGeoPackage symbol in there. But the test simply will not
> > register the driver.
>  
>  
>  
> Does "ogrinfo --formats" report the GPKG driver ?
>  
> I'm connected to IRC (but might not be constantly in front of it. Soon dinner  
> time here)
>  
> >  
> > On Wednesday, November 6, 2013 at 10:54 AM, Paul Ramsey wrote:
> > > Darn, I'm not getting good results for either linking or debugging... set
> > > the DYLD_LIBRARY_PATH and PYTHONPATH appropriately, but
> > >  
> > > In my own test, I cannot even get to the driver load step, basically this
> > >  
> > > gpkg_dr = ogr.GetDriverByName( 'GPKG' )
> > >  
> > > only ever returns 'None'
> > >  
> > > And going into gdb doesn't work either, even on a test that otherwise
> > > works (the sqlite tests will run to completion)
> > >  
> > > Tadpole:~/Code/gdal-git/autotest/ogr pramsey(gpkg)$ gdb python
> > > (gdb) b OGRSQLiteDriver::Open
> > > (gdb) run ogr_sqlite.py
> > > Starting program: /usr/bin/python ogr_sqlite.py
> > > Reading symbols for shared libraries .++..... done
> > > Program received signal SIGTRAP, Trace/breakpoint trap.
> > > 0x00007fff5fc01028 in __dyld__dyld_start ()
> > > (gdb) bt
> > > #0 0x00007fff5fc01028 in __dyld__dyld_start ()
> > >  
> > > On Wednesday, November 6, 2013 at 1:21 AM, Even Rouault wrote:
> > > > Hi Paul,
> > > >  
> > > > > - To test a new driver, you recommend building autotests as you go,
> > > > > yes?
> > > >  
> > > >  
> > > >  
> > > > Yes, that's definitely a good practice. At least they must be written
> > > > at some point for regression testing.
> > > >  
> > > > You can also work with ogrinfo and ogr2ogr. And I'd also advertize the
> > > > use of the test_ogrsf utility, which is a program that checks the
> > > > consistency of a OGR driver by testing that the implementation follows
> > > > the behaviour documented in the API, and also test-stress it a bit. To
> > > > build it, you need to : cd apps
> > > > make test_ogrsf
> > > >  
> > > > And then you use it with "test_ogrsf [-ro] your.gpkg"
> > > >  
> > > > But for that you need a driver that is feature full and an existing
> > > > test file.
> > > >  
> > > > > - But, I cannot even get my autotest script to load the driver... and
> > > > > the test is basically a copy of the sqlite test (which does run and
> > > > > work)
> > > > > https://github.com/pramsey/gdal/blob/gpkg/autotest/ogr/ogr_gpkg.py -
> > > >  
> > > >  
> > > >  
> > > > Looks good.
> > > >  
> > > > > I'm
> > > > > guessing that this is an environment/loading problem? That maybe the
> > > > > python tests are picking up my system libgdal.dylib not the built one
> > > > > in the source tree? What environment variable magic do I need to set
> > > > > to force it to use the right dylib?
> > > >  
> > > >  
> > > >  
> > > > Disclaimer: I have never used any Mac...
> > > >  
> > > > Yes, you should probably try setting DYLD_LIBRARY_PATH to point to the
> > > > path where libgdal.dylib is in your development tree.
> > > >  
> > > > But mixing the default Python bindings from another version with the
> > > > libgdal of your development version isn't particularly recommanded (in
> > > > theory it should work since Python bindings use the GDAL/OGR C API,
> > > > which is stable). I usually build the version of the Python bindings
> > > > that matches my development tree and make sure it is used.
> > > >  
> > > > cd swig/python
> > > > python setup.py build
> > > > export PYTHONPATH=$PWD/build/lib.linux-x86_64-2.6
> > > > (last part of the path to match your OS + Arch + Python version)
> > > >  
> > > > Setting DYLD_LIBRARY_PATH is also probably necessary
> > > >  
> > > > > - Secondly, assuming I do get a test running,
> > > > > how do I attach a debugger to it to track more difficult/deeper
> > > > > issues?
> > > > >  
> > > > > gdb python
> > > > >  
> > > > > > b OGRGeoPackageDriver::Open
> > > > > > run ogr_gpkg.py
> > > > >  
> > > > >  
> > > > >  
> > > > > - Like so? Or is there other magic to debug things loaded into
> > > > > Python?
> > > >  
> > > >  
> > > >  
> > > > Looks good. The above works for me for other drivers.
> > > >  
> > > > $ gdb python
> > > > [...]
> > > > (gdb) b OGRSQLiteDriver::Open
> > > > Can't find member of namespace, class, struct, or union named
> > > > "OGRSQLiteDriver::Open"
> > > > Hint: try 'OGRSQLiteDriver::Open<TAB> or 'OGRSQLiteDriver::Open<ESC-?>
> > > > (Note leading single quote.)
> > > > Make breakpoint pending on future shared library load? (y or [n]) y
> > > > Breakpoint 1 (OGRSQLiteDriver::Open) pending.
> > > > (gdb) run ogr_sqlite.py
> > > > Starting program: /usr/bin/python ogr_sqlite.py
> > > > [Thread debugging using libthread_db enabled]
> > > > TEST: ogr_sqlite_1 ... [New Thread 0x7fffe4425700 (LWP 9243)]
> > > > [Thread 0x7fffe4425700 (LWP 9243) exited]
> > > > success
> > > > TEST: ogr_sqlite_2 ...
> > > > Breakpoint 1, OGRSQLiteDriver::Open (this=0xa5b040,
> > > > pszFilename=0x7ffff7ef3f94 "tmp/sqlite_test.db", bUpdate=1) at
> > > > ogrsqlitedriver.cpp:68
> > > > 68 {
> > > > (gdb)
> > > >  
> > > >  
> > > > Even
>  
> --  
> Geospatial professional services
> http://even.rouault.free.fr/services.html