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

Sun Dec 5 18:23:03 PST 2021

> This is probably my lack of windows knowledge, but is the postgis build
> somehow configured to find the needed shared libraries by looking in
> PATH?   On POSIXy systems, the libraries are looked for in DT_RPATH (or
> RUNPATH, a minor complication not that important).  E.g. objdump -x on
> /usr/pkg/bin/shp2pgsql has this output:
> 
[Regina Obe] 
It looks in the directory of the dependent executable first for dependencies
and then looks in PATH for what it couldn't find in the direct path.
I use the same trick (except export and $ signs)  on Debbie and Berrie (both
Debian bots) and it works there too just overriding the 
PATH

Here is what Berrie64 build script looks like for example:
https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/ci/berrie64/co
nfigs.sh  #configuration where I flip the GEOS as needed
https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/ci/berrie64/pg
_init_start.sh #postgresql startup script

Though I think I had to set the LD_LIBRAY_PATH for building otherwise it
would pick up the system installed GEOS and PostgreSQL  instead of my custom
compiled one.

> so postgis ends up with libgeos.so, but doesn't have a textual reference
> so replacing geos should still work.   I am not finding anything that
> has a direct reference to libgeos, but I remember that happening, and
there are
> notes in pkgsrc about it.  However it does not seeem to be happening any
more.
> >> Well, your real problem is that you are using windows!
> >>
> > [Regina Obe]
> > Is your other name Sandro.  I might not be able to tell you apart
> > anymore :)
> 
> Actually we've never met, but great minds think alike!
> 
> > You solved the problem :)
> >
> > Ldd Shows this:
> > ldd /projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll
> >         :
> >         ucrtbase.dll => /c/Windows/System32/ucrtbase.dll
(0x7ff966af0000)
> >         libgeos_c.dll => not found
> >         :
> >
> > and I see the newer GEOS from 3.10.1 on  have the file called
> > libgeos_c-1.dll copying libgeos_c-1.dll back to the original name of
> > libgeos_c.dll fixed the issue.
> 
> Well that seems messed up.   Renaming the library changes the ABI.
> 
> 
> > I also notice I am back to having this ugly libgeos-3.10.1.dll that I
> > was so happy to get rid of when I had switched my geos building from
> > autotools to CMake years ago.
> 
> Changing to an alternative build system should not result in an ABI
change, and
> if so, one of the build systems is buggy.
> 
> > In GEOS 3.10.0 the c++ one was called:  libgeos_c-1.dll Why is this
> > ugly creature back?
> 
> But you just said that was the name of the C library in 3.10.1.
> 
[Regina Obe] 
All of these were compiled with CMake.  I haven't used libtool on GEOS since
3.6 or so..
In GEOS 3.10.0 (and all cmake versions previous) -- the files in bin folder
are just the way I like them:
geos-config  geosop.exe  libgeos.dll  libgeos_c.dll

and ldd of libgeos_c.dll looks like:
ldd /projects/geos/rel-3.10.0w64gcc81/bin/libgeos_c.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff968c30000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff967c10000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll
(0x7ff9663f0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff968a70000)
        libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
        libgeos.dll => /projects/geos/rel-3.10.0w64gcc81/bin/libgeos.dll
(0x64c40000)
        libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ff967a60000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ff966770000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ff966dd0000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ff966950000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ff966350000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff966af0000)
        IMM32.DLL => /c/WINDOWS/System32/IMM32.DLL (0x7ff967560000)

In GEOS 3.10.1 (where things started sucking as far as file names go)
geos-config  geosop.exe  libgeos-3.10.1.dll  libgeos_c-1.dll  
(I do recall my libtool builds having the full name at least for the c++
part and that libgeos_c-1.dll that is why I assumed it was to congeal the
two systems). 
$ ldd /projects/geos/rel-3.10.1w64gcc81/bin/libgeos_c-1.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff968c30000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff967c10000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll
(0x7ff9663f0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff968a70000)
        libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
        libgeos-3.10.1.dll =>
/projects/geos/rel-3.10.1w64gcc81/bin/libgeos-3.10.1.dll (0x70200000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
        libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ff967a60000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ff966770000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ff966dd0000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ff966950000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ff966350000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff966af0000)
        IMM32.DLL => /c/WINDOWS/System32/IMM32.DLL (0x7ff967560000)

 (symlinks don't work too well under windows so I'm doing a copy)
cp libgeos_c-1.dll libgeos_c.dll

and that fixed my PostGIS.

> > If it was to congeal the libtool / CMake worlds I guess I can learn to
> > live with this ugliness.
> 
> I am not following what is going on with your system.
> 
> Stepping way back and ignoring OS differences, we have two shared
> libraries:
> 
>   libgeos_c which has a stable ABI and hence stable shlib version
> 
>   libgeos which has an unstable ABI, partially because C++ is so
>   complicated that nobody can figgure out if there is an ABI change so
>   C++ libraries tend to change their shlib major version every release.
> 
[Regina Obe] 
When I built with libtool it did that.
When I switched to CMAKE -- to my delight the C++ one never changed names
Was just libgeos.dll

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. 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.  
Those extra C++ were just a nuisance cause PostGIS uses the C-API and I'd
have to remove them in uninstall or have them build up.

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

Thanks,
Regina