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

actually, even more importantly the reason to drop this is because it is wrong on linux. When building gdal it will link to a specific version of libproj (ex libproj.so.3), with the current implementation, at runtime it will try to load libproj.so. This does not existing in non -dev packages

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

dal-dev-boun...@lists.osgeo.org> on behalf of Howard Butler <how...@hobu.co> Sent: Sunday, May 7, 2017 9:47:26 AM To: Frank Warmerdam Cc: gdal dev Subject: Re: [gdal-dev] Dropping dlopen/LoadLibrary loading of proj.4 ? I'm +1 on this. I too found it confusing that Proj.4 worked in this way a

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

I'm +1 on this. I too found it confusing that Proj.4 worked in this way and no other libraries did in GDAL. > I my case, I *cannot* distribute proj4 into my GDAL build and I *need* to > have the options to let the user decided if they want to add proj4 shared > libraries. Ivan, I don't

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

Even, I'm +0 on this change. On the one hand, I *like* the fact that the dlopen() approach means that adding libproj.so after the fact means that GDAL starts supporting coordinate system conversion without a rebuild. On the other hand, it isn't clear why we do this only for libproj. I have

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

ht? Regards, Ivan From: gdal-dev <gdal-dev-boun...@lists.osgeo.org> on behalf of Kurt Schwehr <schw...@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 Ma

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

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 ?

al dev Subject: Re: [gdal-dev] Dropping dlopen/LoadLibrary loading of proj.4 ? 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 s

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

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

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

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

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

+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 ?

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 >

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

+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

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

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