-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 <[email protected]> on behalf of Kurt Schwehr <[email protected]> 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" <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
