This is in main now. P
> On Jun 14, 2022, at 11:05 AM, Regina Obe <l...@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:manisan...@gmail.com] >> Sent: Tuesday, June 14, 2022 1:50 PM >> To: Regina Obe <l...@pcorp.us>; 'GEOS Development List' <geos- >> de...@lists.osgeo.org>; roger.biv...@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-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
