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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev