[gdal-dev] Re: VRT Derived Bands from Python?

Even Rouault even.rouault at mines-paris.org
Fri May 13 13:07:31 EDT 2011


Le vendredi 13 mai 2011 18:59:14, Knut-Frode Dagestad a écrit :
> On 13/05/2011 12:07, Antonio Valentino wrote:
> > If you think it is useful I can attach the fake-driver code to the
> > #3367.
> 
> Thank you, that would be useful.
> 
> In the meantime I have tested this approach, nearly successful:
> I copied one of your pixel-functions from #3367 and made a dynamic
> library file with:
> 
> gcc -fPIC -c gdal_nerscpixelfun.c
> gcc -shared -lgdal -o gdal_nerscpixelfun.so gdal_nerscpixelfun.o
> 
> and then set GDAL_DRIVER_PATH to point to this folder.
> 
> However, at GDAL startup I get the following error:
> ERROR 1: dlsym(0x100e095f0, _GDALRegister_nerscpixelfun): symbol not found

I had also a similar error on Linux, but it worked despite the error. I have 
pushed a fix in trunk to silent that error. You can try to add a printf() 
statement in your GDALRegisterMe function to check if it is loaded correctly.

Explanation : GDAL tries to load first a symbol called GDALRegister_xxxxx when 
the .so is called gdal_xxxxxx.so/dll, and if not present it then tries 
GDALRegisterMe. There's no point emitting an error if GDALRegister_xxxxx is 
not found, but GDALRegisterMe is found. See 
http://trac.osgeo.org/gdal/changeset/22359

I'm not a MacOSX user, but I believe that on the Mac, shared libraries have to 
be suffixed by .dylib instead of .so. That might explain your error if it 
doesn't work.

> 
> Any ideas what is wrong? OS is Mac OS X 10.6.7. I am not a C expert.
> 
> Best regards from Knut-Frode
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


More information about the gdal-dev mailing list