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