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

Greg Troxel gdt at lexort.com
Sun Dec 5 17:31:08 PST 2021 

"Regina Obe" <lr at pcorp.us> writes:

>> > So my PostGIS is compiled with GEOS 3.9.0, but it should work with
>> > GEOS 3.11.
>> 
>> You presumably have swapped out the geos implementation?  How?
>> 
> [Regina Obe] 
> I test PostGIS / PostgreSQL with a PostgreSQL launch script that sets the
> path of all the key dependencies.
> So I have a compiled (lots of other old geos) , GEOS 3.9.0, GEOS 3.10.0,
> GEOS 3.10.1, GEOS 3.11 (main) all just different in bin path by the version.
>
> So when I want to compare differences I compile PostGIS with the lowest
> version I want to compare
> And then switch the paths in my PG launch script and then start up
> PostgreSQL again.
>
> Ignore the windowishness of this script, pretend you see export and $ signs
> instead
> -- START SCRIPT --
> SET OS_BUILD=64
> SET GCC_TYPE=gcc81
> SET MINGW=C:\ming%OS_BUILD%%GCC_TYPE%\mingw%OS_BUILD%
> SET PROJECTS=C:\ming%OS_BUILD%%GCC_TYPE%\projects
> SET GDAL_VER=3.3.3
> #I change this
> SET GEOS_VER=3.10.1
> SET PGDATA=%~dp0\data
> SET PGDATABASE=postgres
> SET PGUSER=postgres
> SET PGPORT=5451
> : lots of other dependencies cut out to keep this shorter
> @SET
> PATH=%PROJECTS%\zlib\rel-zlib-%ZLIB_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%
> \CGAL\rel-cgal-%CGAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\cgal\rel-sfcga
> l-%SFCGAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%MINGW%\bin;%~dp0bin;%PROJECTS%\gdal
> \rel-%GDAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\geos\rel-%GEOS_VER%w%OS_
> BUILD%%GCC_TYPE%\bin;%PROJECTS%\rel-libiconv-%ICONV_VER%w%OS_BUILD%%GCC_TYPE
> %\bin;%PROJECTS%\proj\rel-%PROJ_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\lib
> xml\rel-libxml2-%LIBXML_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\curl\rel-cu
> rl-%CURL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\expat\rel-expat-%EXPAT_VER
> %w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\freexl\rel-freexl-%FREEXL_VER%w%OS_BUI
> LD%%GCC_TYPE%\bin;%PROJECTS%\v8\%V8_VER%;%PROJECTS%\ssl\rel-openssl-%OPENSSL
> _VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\sqlite\rel-sqlite%SQLite_VER%w%OS_
> BUILD%%GCC_TYPE%\bin;%PROJECTS%\protobuf\rel-%PROTOBUF_VER%w%OS_BUILD%%GCC_T
> YPE%\bin;%PROJECTS%\pcre\rel-%PCRE_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\
> lz4\rel-lz4-%LZ4_VER%w%OS_BUILD%%GCC_TYPE%\bin;%~dp0\bin
>
> "%~dp0\bin\initdb" -E UTF8 -U postgres -A trust
> "%~dp0\bin\pg_ctl" -D "%~dp0/data" -l logfile_%PGPORT% start
>
> ECHO "Click enter to stop"
> pause
> "%~dp0\bin\pg_ctl" -D "%~dp0/data" stop -m fast
> -- END SCRIPT --

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:


  NEEDED               libgeos_c.so.1
  NEEDED               libproj.so.15
  NEEDED               libsqlite3.so.1
  NEEDED               libpthread.so.1
  NEEDED               libm.so.0
  NEEDED               libjson-c.so.5
  NEEDED               libintl.so.1
  NEEDED               libc.so.12
  RPATH                /usr/pkg/lib:/usr/X11R7/lib

and the same on the postgis so (that's dynamically loaded into
postgresql, AIUI) is

  NEEDED               libm.so.0
  NEEDED               libc++.so.1
  NEEDED               libgeos_c.so.1
  NEEDED               libproj.so.15
  NEEDED               libjson-c.so.5
  NEEDED               libprotobuf-c.so.1
  NEEDED               libxml2.so.2
  NEEDED               libz.so.1
  NEEDED               liblzma.so.2
  NEEDED               libc.so.12
  NEEDED               libstdc++.so.9
  RPATH                /usr/pkg/lib:/usr/X11R7/lib


Earlier I talked about libgeos being added in, but it seems at least in
the postgis build that is not happening.

libgeos_c has:

  NEEDED               libgeos.so.3.10.1
  NEEDED               libstdc++.so.9
  NEEDED               libm.so.0
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.12
  SONAME               libgeos_c.so.1
  RPATH                /usr/pkg/lib
 
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.

> 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.

and each release's libgeos_c has DT_NEEDED (or equivalent on windows?)
to that releases libgeos.

On my system I have

  lrwxr-xr-x  1 root  wheel       17 Nov  3 17:53 /usr/pkg/lib/libgeos.so -> libgeos.so.3.10.1
  -rwxr-xr-x  1 root  wheel  3254048 Nov  3 17:53 /usr/pkg/lib/libgeos.so.3.10.1
  lrwxr-xr-x  1 root  wheel       14 Nov  3 17:53 /usr/pkg/lib/libgeos_c.so -> libgeos_c.so.1
  lrwxr-xr-x  1 root  wheel       19 Nov  3 17:53 /usr/pkg/lib/libgeos_c.so.1 -> libgeos_c.so.1.16.0
  -rwxr-xr-x  1 root  wheel   315936 Nov  3 17:53 /usr/pkg/lib/libgeos_c.so.1.16.0

  $ ldd /usr/pkg/lib/libgeos_c.so
  /usr/pkg/lib/libgeos_c.so:
          -lgeos.3.10.1 => /usr/pkg/lib/libgeos.so.3.10.1
          -lstdc++.9 => /usr/lib/libstdc++.so.9
          -lm.0 => /usr/lib/libm.so.0
          -lc.12 => /usr/lib/libc.so.12
          -lgcc_s.1 => /usr/lib/libgcc_s.so.1

which makes sense to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20211205/b0e2d3b7/attachment.sig>

More information about the geos-devel mailing list