[gdal-dev] Autotest/Driver Registration Help

[Paul Ramsey]

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. 

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




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
>