[geos-devel] mingw64 file libs changed

[Regina Obe]

Yap that works for me. 

> -----Original Message-----
> From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Tuesday, June 14, 2022 12:26 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
> 
> 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/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
> >
> > _______________________________________________
> > 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