Actually, I remember now that on Linux I've observed plugin loading
issues specific to loading in Python when I forget to link the plugin to
libgdal itself. This doesn't show up when loading the plugin from a GDAL
command line utility.
Le 14/12/2023 à 22:19, Even Rouault via gdal-dev a écrit :
- If you build a plugin against GDAL X.Y, you must run it against GDAL
X.Y, and not an earlier or later version since the C++ ABI changes
between feature versions (you should however be able to use a plugin,
built against X.Y.some_patch_version, against X.Y.another_path_version)
- The error you get about specified procedure not found generally
indicate that your plugin links to some library that is not found in
the PATH / LD_LIBRARY_PATH. dlopen() / LoadLibrary() aren't super
verbose about the reasons. You might have to use ldd or
DependencyWalker to figure out the runtime linking issue.
- If you use GDALRegister_X(), then your DLL must be called exactly
"gdal_X.dll" / "gdal_X.so" . Or use "GDALRegisterMe()" as the
registration function. GDALRegister_X or GDALRegisterMe must have C
export style (extern "C").
- Before trying GDALOpen(), check with "gdalinfo --format X" that your
driver is loaded.
Le 14/12/2023 à 21:52, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] via gdal-dev a écrit :
Hi,
After carefully following the advice here on the lists and the Raster
driver tutorial GDAL isn’t loading the driver.
I am relying on the AutoLoadDrivers function.
When I GDALAllRegister(), followed by a
GDALOpen(“path/to/custom/raster.ext”, RA_ReadOnly);, GDAL states that
the file is not recognized as a supported file format. The
application was built against the exact version of GDAL used to link
the custom driver code. GDAL 3.7.2
I tried running an older GDAL version (3.6.3) in a python
environment. When I `from osgeo import gdal`, there are two errors
that are printed.
1. Can’t load requested DLL – then it printed the full path and file
name of the driver .dll, so it can find it!
2. The specified procedure could not be found
These look like python specific error messages to me, and probably
stem from a gdal version mismatch. I’m assuming #2 is emitted in a
trivial sense because the .dll could not be opened. Curiously the
error message was printed twice. I did not expect this to work but
my hope was to see a more detailed error message.
I have exported the GDALRegister_X() function, in accordance with the
documentation. The driver code compiles cleanly and follows almost
verbatim with the tutorial.
How should I approach diagnosing the problem?
Best,
Jesse
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
