[geos-devel] mingw64 file libs changed

Sandro Mani manisandro at gmail.com
Tue Jun 14 13:18:41 PDT 2022


Ah now I understand, I had interpreted

 > 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.

as if the issue was determining the link library name.

Sandro

On 14.06.22 20:05, Regina Obe 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/ucrt
>>>>> 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/ucrt
>>>>> 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


More information about the geos-devel mailing list