[geos-devel] mingw64 file libs changed

Paul Ramsey pramsey at cleverelephant.ca
Tue Jun 14 09:25:35 PDT 2022


I'm tempted to put the versioned MinGW stuff behind an option and return to the default cmake output by default.
That doesn't get to your "ideal" scenario Regina, that would have to be yet another option, since most people are not probably going to want to totally hide the c++ DLL inside the c DLL.
But it's closer to what you were happy with before.
???
P

> On Jun 14, 2022, at 9:21 AM, Regina Obe <lr at pcorp.us> 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/ucrt3/
>>> 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/ucrt3/
>>> 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



More information about the geos-devel mailing list