On 14.06.22 01:31, Regina Obe wrote:
So what's your interest in mingw64?
Are you building mingw64 packages on Fedora?
Yes, resp. Fedora offers a fairly large collection of mingw packages in
its repos. These can be used to cross-compile an application to Windows
from Fedora.
The thing is libgeos_c.dll never changes (I'm fine with a c_1.dll for that)
But the c++ api is unstable.
So why do I want this changing in every micro release when all that should be
used is the C-API by packagers which is stable?
Well that's actually the reason why versioning is useful. If dependent
packages use the unstable API of GEOS (whether they should or should
not), you can pick up which are doing so by scanning the requires of the
dependent packages for libgeos-$version.dll, and rebuild these when
pushing the new GEOS version.
-----Original Message-----
From: Sandro Mani [mailto:manisan...@gmail.com]
Sent: Monday, June 13, 2022 1:33 PM
To: GEOS Development List <geos-devel@lists.osgeo.org>; Regina Obe
<l...@pcorp.us>
Subject: Re: [geos-devel] mingw64 file libs changed
Hi
I'm actually packaging for Fedora.
In short, autotools (and more recently, meson) both add suffixes to the
shared library names with version number, cmake does not do so, but
apparently just because no-one actually pursued it [1].
Why is it useful?
- Quickly picking out which packages need to be rebuild when a dependent
package which carries an ABI incompatibilty is updated (i.e. dnf repoquery --
whatrequires 'mingw64(libgeos_c-1.dll)'). This is *very* useful for packaging.
- Actually even noticing when an ABI incompatibility arises. Packagers often
spot ABI incompatibilities when the so version of a library is bumped. This
clearly requires upstream to properly set and update the soversion.
- For the same reason as above, versioned requires between packages
- Potentially, allowing parallel versions without DLL name collisions
Thanks
Sandro
[1] https://gitlab.kitware.com/cmake/cmake/-/issues/21716
On 13.06.22 19:10, Regina Obe wrote:
Is there a way in CMake to make this an option.
I wouldn't want to inconvenience someone to satisfy me.
If I could have a switch I can turn on to get the old CMAKE behavior
I'd be very happy.
My use case is different from Manisandro. He's probably packaging for
pacman.
In my case, I can only ever have one geos version for each version of
PostgreSQL. Those all live in the respective PostgreSQL versioned
folders
PostgreSQL/14/bin , PostgreSQL/15/bin ...
-----Original Message-----
From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On
Behalf Of Paul Ramsey
Sent: Monday, June 13, 2022 12:32 PM
To: GEOS Development List <geos-devel@lists.osgeo.org>
Subject: Re: [geos-devel] mingw64 file libs changed
On Jun 13, 2022, at 9:29 AM, Regina Obe <l...@pcorp.us> wrote:
Okay guess the question has been answered by
https://github.com/manisandro/geos/commit/927e442ab1da361d3f487e2b6
20a
878dd1
1f191d
I'll have to live with it moving forward.
I wouldn't say so necessarily. I took in a commit from someone with
an opinion on MinGW (I had no opinion, so I took the commit) but the
discussion
in GDAL shows other MinGW people with other opinions, and,
importantly I think, the folks at CMake (who see a *lot* of build
cases) have not chosen
to
just slam in a file prefix on MinGW targets that have an SOVERSION
set,
even
though they do so on when generating outputs for other platforms.
So I'd say it is very much up to you, as someone who has MinGW opinions.
P
Thanks,
Regina
-----Original Message-----
From: Regina Obe [mailto:l...@pcorp.us]
Sent: Monday, June 13, 2022 12:01 PM
To: 'GEOS Development List' <geos-devel@lists.osgeo.org>
Subject: mingw64 file libs changed
I mentioned this on IRC, and Paul is looking into why the change
was
made.
I'm mentioning here in case someone knows the reason. Why was this
change made?
The library files on mingw64 changed:
For geos < 3.11 the files were
libgeos.dll, libgeos_c.dll
For geos 3.11 (including the just released 3.11.0beta1)
libgeos_c-1.dll, libgeos-3.11.0.dll
_______________________________________________
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
