Yap that works for me. > -----Original Message----- > From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of > Paul Ramsey > Sent: Tuesday, June 14, 2022 12:26 PM > To: GEOS Development List <geos-devel@lists.osgeo.org> > Cc: roger.biv...@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 <l...@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-boun...@lists.osgeo.org] On > >> Behalf Of Sandro Mani > >> Sent: Tuesday, June 14, 2022 8:00 AM > >> To: roger.biv...@nhh.no; GEOS Development List <geos- > >> de...@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@lists.osgeo.org > >> https://lists.osgeo.org/mailman/listinfo/geos-devel > > > > _______________________________________________ > > geos-devel mailing list > > geos-devel@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/geos-devel > > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
