[geos-devel] mingw64 file libs changed

Paul Ramsey pramsey at cleverelephant.ca
Wed Jun 15 10:08:20 PDT 2022



> On Jun 15, 2022, at 9:32 AM, Regina Obe <lr at pcorp.us> wrote:
> 
> Now I see libgeos_c-1.dll and libgeos.dll.
> 
> It's different from 3.9 and 3.10, which had libgeos_c.dll for the c-api lib
> file but I'm fine with that.  Just want to make sure you intended to keep
> that change.

Nope, missed a spot. Main should be back to original behaviour now.

P

> 
> Thanks,
> Regina
> 
> 
>> -----Original Message-----
>> From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of
>> Paul Ramsey
>> Sent: Wednesday, June 15, 2022 12:17 PM
>> To: GEOS Development List <geos-devel at lists.osgeo.org>
>> Cc: Roger.Bivand at nhh.no
>> Subject: Re: [geos-devel] mingw64 file libs changed
>> 
>> This is in main now.
>> 
>> P
>> 
>>> On Jun 14, 2022, at 11:05 AM, Regina Obe <lr at pcorp.us> wrote:
>>> 
>>> Sandro,
>>> 
>>> I'm not sure I understand your question.
>>> 
>>> The issue is not the linking of my code. It's the dependency of
>>> 
>>> libgeos_c-1.dll
>>> 
>>> To libgeos-3.11.0.dll
>>> 
>>> I am trying to get rid of.
>>> 
>>> All my code ends up having a dependency on libgeos_c-1.dll  (before
>>> libgeos_c.dll) Which before linked to a unversioned libgeos.dll (this
>>> libgeos.dll was always called that so could be cleanly removed and
>>> replaced)
>>> 
>>> I don't care about if the c dll is called libgeos_c-1.dll or
> libgeos_c.dll.
>>> It's the annoyance of that c++ dll changing with every micro release.
>>> Cause these are harder to predict and uninstall as part of an install
> process.
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Sandro Mani [mailto:manisandro at gmail.com]
>>>> Sent: Tuesday, June 14, 2022 1:50 PM
>>>> To: Regina Obe <lr at pcorp.us>; 'GEOS Development List' <geos-
>>>> devel at lists.osgeo.org>; Roger.Bivand at nhh.no
>>>> Subject: Re: [geos-devel] mingw64 file libs changed
>>>> 
>>>> Can you point me to the Makefile / ... which is doing this linking?
>>>> It should never be necessary to point to a versioned shared library
>>>> name in a link command line. Static libraries are unversioned, and
>>>> for the dynamic libraries the corresponding import libraries are also
>> unversioned.
>>>> 
>>>> Sandro
>>>> 
>>>> On 14.06.22 18:21, Regina Obe wrote:
>>>>> In my case, I need the c++ library statically linked into the geos
> C-api.
>>>>> I need the geos c-API shared but not the c++ one.  The main reason
>>>>> for need of c-api shared is all the extensions I ship rely on that.
>>>>> So I don't want both statically linked.
>>>>> 
>>>>> Also for regression testing I do want to replace the c-lib without
>>>>> having to recompile all my extensions.
>>>>> 
>>>>> Dan and strk had suggested a way to have the c++ be object .a so it
>>>>> can be statically linked to the c lib.
>>>>> I'm not sure how to do that in Cmake or if it is even currently
> possible.
>>>>> 
>>>>> So Sandro - my annoyance with your change is now I have this extra
>>>>> c++ lib to worry about which was always a static name before and now
>>>>> is changing with each micro release.
>>>>> 
>>>>> Thanks,
>>>>> Regina
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org] On
>>>>>> Behalf Of Sandro Mani
>>>>>> Sent: Tuesday, June 14, 2022 8:00 AM
>>>>>> To: Roger.Bivand at nhh.no; GEOS Development List <geos-
>>>>>> devel at lists.osgeo.org>
>>>>>> Subject: Re: [geos-devel] mingw64 file libs changed
>>>>>> 
>>>>>> Just a note: library versioning only applies to shared libraries,
>>>>>> static
>>>>> libraries
>>>>>> are unversioned. And FWIW, import libraries are also unversioned.
>>>>>> So no
>>>>> link
>>>>>> command should be affected (unless you are linking against the dll
>>>>>> shared library rather than the dll.a import library).
>>>>>> 
>>>>>> Sandro
>>>>>> 
>>>>>> On 14.06.22 12:59, Roger Bivand wrote:
>>>>>>> In R >= 4.2, Windows static linked binary packages linking to GEOS
>>>>>>> use MXE, locally updating the MXE use of GEOS 3.6.2 to 3.9.1:
>>>>>>> 
>>>>>>> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/uc
>>>>>>> rt
>>>>>>> 3/
>>>>>>> toolchain_libs/mxe/src/geos.mk
>>>>>>> 
>>>>>>> 
>>>>>>> We currently hot-patch geos-config to modify it for static libs:
>>>>>>> 
>>>>>>> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/uc
>>>>>>> rt 3/ toolchain_libs/mxe/src/geos-1-fixes.patch
>>>>>>> 
>>>>>>> 
>>>>>>> We could hot-patch files in a GEOS >= 3.11.0 tarball to remove
>>>>>>> instructions creating versioned libraries, but have not yet tested
>>>>>>> RC1. R packages also need to list static linked libraries by name,
>>>>>>> and revising each of a dozen or so at each GEOS release would be
>>>>>>> error
>>>>> prone.
>>>>>>> Is a cmake option a way to satisfy both those needing versioned,
>>>>>>> or unversioned library names?
>>>>>>> 
>>>>>>> Does anyone else use MXE; if so, might it make sense to feed
>>>>>>> changes in GEOS forward to MXE?
>>>>>>> 
>>>>>>> Best wishes,
>>>>>>> 
>>>>>>> Roger
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> geos-devel mailing list
>>>>>> geos-devel at lists.osgeo.org
>>>>>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>> 
>>> _______________________________________________
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>> 
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> 



More information about the geos-devel mailing list