[GRASS-dev] Reasons for GDAL dynamic library load in code?

[Vaclav Petras]

Given that the original motivation is unknown and that we would not do the
same now, i.e., we would treat GDAL as any other library, it seems we can
go ahead.

The only reason I can think of is GRASS driver for GDAL which introduces a
cyclic dependency, but if anything is needed, it is perhaps solved in GDAL.

On Thu, 7 Apr 2022 at 11:10, Vaclav Petras <wenzeslaus at gmail.com> wrote:

> Hi devs,
>
> We are about to remove dynamic loading of GDAL from the raster library
> code in #2290. GDAL will then be loaded as any other library by the system.
>
> https://github.com/OSGeo/grass/pull/2290
>
> Currently, the libraries are loaded with dlopen and LoadLibrary and
> GDAL_DYNAMIC is set to enable that code. This was introduced in 2008 by
> Glynn in r33559.
>
>
> https://github.com/OSGeo/grass/commit/265039761908433c58b07b9b47fcb16f5126e88c
> https://trac.osgeo.org/grass/changeset/33559
>
> To be sure removing it completely is a good step, I wanted to check the
> original motivation. Any ideas? The commit message doesn't mention the
> motivation and I'm not getting anything from Internet searches.
>
> Let me know what you think.
>
> Best,
> Vaclav
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20220412/9d8b9190/attachment.html>