[geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0

[Regina Obe]

>> I know it probably sucks for most people, but for me it was great, cause
it
>> meant I don't have to deal with removing those
>> Old 3.10.0, 3.9.0 etc when I build installers.

> I would expect some packaging system that would remove them at
> uninstall/replace time.

My installer does remove them at uninstall time.
The issue is people rarely uninstall, they just install new versions of
PostGIS
Which happen to need to be looking for the same compatible version of GEOS.
So these versioned dlls that are not needed just keep piling up.
Cause next install libgeos_c-1.dll will be tied to libgeos-3.10.1.dll
instead of libgeos-3.9.0.dll.

I'm okay with having a libgeos_c-1.dll and yes with mindset there might be a
libgeos_c-2.dll
I can live with that versioning.  It's this extra C++ baggage I don't need.

But my packaging of GEOS is a special case packaging.  
Its purpose is to just be used by PostGIS for a specific version of
PostgreSQL and include all the
dependencies that PostGIS needs to live that are not already shipped by EDB
(windows PostgreSQL installer).


>> Generally on windows people
>> have a habit of installing multiple versions of 
>> PostGIS in the same PostgreSQL instance, but they all have to share the
same
>> GEOS.  

> I had not idea that could be done, and surely they must have
> non-overlapping names?

They don't need non-overlapping names, cause they are installed in separate
folders.

If someone has 3 versions of PostgreSQL installed, then they have 3 installs
of geos all in the PostgreSQL system folder for that version.
e.g c:\program files\PostgreSQL\14\bin,  c:\program files\PostgreSQL\13\bin
and so on
 (cause it's not installed in system).  So in theory  each PostgreSQL
version can have a different version of geos.
However all versions of PostGIS installed in a specific PostgreSQL install
share the same geos regardless
So installing PostGIS 3.1 would upgrade your GEOS that was installed by
PostGIS 3.0 and so on.
Cause they'd all be in theory pointing at the one and only libgeos_c-1.dll
in the PostgreSQL/<version number>/bin folder.


>>  I would love to just statically link those two together and have just
one
>> library to contend with.

> As soon as you do that it get really iffy about claiming new geos
> versions do not have an ABI change.  Part of the point is that the C++
> interface is not available to client programs.

> And, that would seem to be a workaround for confusion within Windows
> about shared library naming.

I don't think there is a confusion here, just don't like seeing yet another
library file :)
Windows points at the libgeos-3.10.1 whatever longish versioned names. 
Like I said though my use case is a little different, it's very isolated
from rest of windows environment.
So this extra junk (I know you and strk think it's not) is a nuisance.
I can see how it's useful in a system shared environment.  
Not so much when the environment is very isolated from the system.


> I wonder if someone can explain how windows dll versioning is supposed
> to work?   I don't understand it (and I bet strk doesn't either).
Do you really want to understand it?  Strk doesn't.
I think within a 2-3 year span, windows will morph into some forkish version
of Debian/Ubuntu
and then all that knowledge will not be that useful anyway.

I agree with you the new way is saner, just a little more inconvenient. 

So I guess nothing to fix.  The old way was broken in a way I considered a
"feature".
The new way is a saner solution but not as pleasant from where I am
standing.

Thanks for the help and thoughts and listening to my rants,
Regina