[gdal-dev] Autotest/Driver Registration Help

Wed Nov 6 12:09:54 PST 2013

Mystery "solved".

When running 'python', the python ogr libraries were being
preferentially loaded from /Library/Frameworks/GDAL, the package
installed with the OSX QGIS build from KyngChaos, regardless of the
value of the PYTHONPATH variable. That framework in turn seems to have
preferentially loaded its own libgdal, regardless of the value of the
DYLD_LIBRARY_PATH.

So, when working with the GDAL python autotest routines: BEWARE any
GDALs that might be in your frameworks directory.

P.

On Wed, Nov 6, 2013 at 11:41 AM, Paul Ramsey <pramsey at boundlessgeo.com> wrote:
> 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev