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

[Ivan Lucena]

Hi Howard,


Yep. It is a license issue but I am not going to get into the details.


But apart from that, lets think about other scenarios:


An application is using GDAL and Proj4 and someone decide to update GDAL to get some bug fixes.


But GDAL is build *without* static Proj4 and therefore is blind to the presence of Proj4 shared library.


That would be a problem. Right?


Anyway. If the change makes sense and it is for the better. And it is for a new release (no backport).


+0 ( I can't vote anyway)


Best regards,


Ivan



________________________________
From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> on behalf of Howard Butler <howard at 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 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 understand the scenario here. It isn't a licensing thing to prevent you from distributing Proj.4, and what do you do in the case of all of the other shared libraries that are linked at compile time that GDAL uses?

Howard

>
> On May 7, 2017, at 3:01 AM, Frank Warmerdam <warmerdam at pobox.com> wrote:
>
> 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 some appreciation for Ivan's stated concerns with regard to
> regression, but I don't think that should hold back cleanup in major
> new versions.
>
> Best regards,
> Frank
>
>
> On Sat, May 6, 2017 at 12:09 PM, Even Rouault
> <even.rouault at spatialys.com> wrote:
>> 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 notes... There are a number of
>> breaks in each new release. That's not really different. And the way of
>> solving in the case you mention is rather simple.
>>
>>
>>
>>> I my case, I *cannot* distribute proj4 into my GDAL build
>>
>>
>>
>> I've the feeling you're abusing -1 for a reason which you mentionned
>> privately to me but in my opinion isn't really valid for the rest of the
>> community. But this is not an important enough topic for me to fight about
>> and create useless tensions among contributors.
>>
>>
>>
>> So I'm dropping the ball on this. For posterity, my patch is at:
>>
>> https://trac.osgeo.org/gdal/ticket/6882
>>
>>
>>
>>
>>
>> Even
>>
>>
>>
>> --
>>
>> Spatialys - Geospatial professional services
>>
>> http://www.spatialys.com
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows |
> and watch the world go round - Rush    | Geospatial Software Developer
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
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/20170508/66605527/attachment.html>