[geos-devel] mingw64 file libs changed

Sandro Mani manisandro at gmail.com
Mon Jun 13 23:04:40 PDT 2022


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:manisandro at gmail.com]
>> Sent: Monday, June 13, 2022 1:33 PM
>> To: GEOS Development List <geos-devel at lists.osgeo.org>; Regina Obe
>> <lr at 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-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


More information about the geos-devel mailing list