[gdal-dev] Motion: adopt RFC 96: Deferred C++ plugin loading

[Kurt Schwehr]

+1 KurtS

One minor comment...

I use pfnOpen in a few of my local fuzzers, but I build statically without
plugins, so I think my use won't be impacted. But even if I am impacted,
that's my problem and not a responsibility of the GDAL project as I'm using
internal GDAL details.

> Another potential issue is that if external code would directly use the
pfnOpen, pfnCreate, pfnCreateCopy, etc. function pointers of a GDALDriver
instance, it would see them null before the actual driver is loading, but
direct access to those function pointers has never been documented (instead
users should use GDALOpen(), GDALCreate(), GDALCreateCopy() etc), and is
not expected to be done by code external to libgdal core.

On Wed, Nov 15, 2023 at 1:52 AM Even Rouault via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Hi,
>
> Motion: adopt RFC 96: Deferred C++ plugin loading
>
> https://github.com/OSGeo/gdal/pull/8648
>
> Pre-rendered view:
>
>
> https://github.com/rouault/gdal/blob/rfc96_text/doc/source/development/rfc/rfc96_deferred_plugin_loading.rst
>
>
> Starting with my +1,
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20231115/c3ed6d4c/attachment.htm>