[gdal-dev] Dropping dlopen/LoadLibrary loading of proj.4 ?

[Ivan Lucena]

-1


We have the options to build drivers against static and dynamic libraries of its SDKs, like HDF4,5 and openjpeg for example, using the same "--with-driver-name"


Why not keep that same option for proj4?


--with-proj4=<static or dynamic>-library-path


I have projects where I let user to decide if they want to download and install proj4 while using GDAL and I would prefer to keep that option.


Maybe with a compiler option we can basically "remove" the dynamic load when static linked proj4 was used. Config can translate the --with-proj4 into a C++ define, right?


Regards,

Ivan


________________________________
From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> on behalf of Kurt Schwehr <schwehr at gmail.com>
Sent: Saturday, May 6, 2017 11:20:34 AM
To: Even Rouault
Cc: gdal dev
Subject: Re: [gdal-dev] Dropping dlopen/LoadLibrary loading of proj.4 ?

+1

On May 6, 2017 4:58 AM, "Even Rouault" <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> wrote:

Hi,



Currently the default mode of linking GDAL with proj.4 is to use dynamic loading mechanism (dlopen on Unix, LoadLibary on Windows). I believe the reason for that was that it could have make it easier to use an alternate projection engine, but apparently nobody cared enough to plug a new one, and it could be done with standard linking. One downside of the current mechanism (besides code complication) is that it requires to list the exact library name of proj4 in GDAL source code, which can change depending on the soname of proj4. And this can cause subtle issues like

https://trac.osgeo.org/gdal/ticket/6881



So I'd suggest just keeping standard linking mechanism, and renaming the current --with-static-proj4 configure flag as --with-proj4, as the current name is confusing, and making it the default behaviour.



Any thoughts ?



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto: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/20170506/d4192fbf/attachment-0001.html>