[geos-devel] mingw64 file libs changed

[Sandro Mani]

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-bounces at lists.osgeo.org] On Behalf Of
>> Paul Ramsey
>> Sent: Monday, June 13, 2022 12:32 PM
>> To: GEOS Development List <geos-devel at lists.osgeo.org>
>> Subject: Re: [geos-devel] mingw64 file libs changed
>>
>>
>>
>>> On Jun 13, 2022, at 9:29 AM, Regina Obe <lr at 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:lr at pcorp.us]
>>>> Sent: Monday, June 13, 2022 12:01 PM
>>>> To: 'GEOS Development List' <geos-devel at 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 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