[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