[gdal-dev] Autotest/Driver Registration Help

[Even Rouault]

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