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

2017-05-06 Thread Even Rouault
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

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

2017-05-06 Thread Kurt Schwehr
+1 On May 6, 2017 4:58 AM, "Even Rouault" 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 > project

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

2017-05-06 Thread Even Rouault
On samedi 6 mai 2017 13:58:06 CEST Even Rouault 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 > project

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

2017-05-06 Thread Zachary Flamig
+1 I’ve been tricked by this several times where I think I have gdal successfully compiled and then go to reproject something only to find out it can’t :-( Zac > On May 6, 2017, at 10:20 AM, Kurt Schwehr wrote: > > +1 > > On May 6, 2017 4:58 AM, "Even Rouault"

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

2017-05-06 Thread Even Rouault
On samedi 6 mai 2017 17:04:33 CEST Ivan Lucena wrote: > -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? I think you are c

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

2017-05-06 Thread Even Rouault
Ivan, > I understand the good intention of cleaning up code but that should not > remove functionality. You are breaking backward compatibility. What if > someone updates GDAL in some installation, proj4 is there and it will not > going to be used? Well that would be documented in the release not

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

2017-05-06 Thread Ivan Lucena
HI Even, I understand the good intention of cleaning up code but that should not remove functionality. You are breaking backward compatibility. What if someone updates GDAL in some installation, proj4 is there and it will not going to be used? I my case, I *cannot* distribute proj4 into my GD

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

2017-05-06 Thread Andrew C Aitchison
On Sat, 6 May 2017, Even Rouault wrote: I'm intending to drop support for proj.4 < 4.8 too to do some cleanups Red Hat / Centos / Scientific Linux 6 use proj4 v4.8.x so I have no problem with this. -- Andrew C. Aitchison Cambridge, UK

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

2017-05-06 Thread 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=-library-path I have projects where I let user to decide if they want t