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

[Vaclav Petras]

Merged into the main branch as adde62ef.

https://github.com/OSGeo/grass/commit/adde62ef22bad90c337580afff925be4e646abe2

On Tue, 12 Apr 2022 at 10:09, Vaclav Petras <wenzeslaus at gmail.com> wrote:

> 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/20220419/d21222bd/attachment.html>