Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
> 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 (0x7ff966af) > > 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 (0x7ff968c3) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff967c1) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ff9663f) msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff968a7) libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x6144) libgeos.dll => /projects/geos/rel-3.10.0w64gcc81/bin/libgeos.dll (0x64c4) libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc4) libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x6494) USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ff967a6) win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ff96677) GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ff966dd) gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ff96695) msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ff96635) ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff966af) IMM32.DLL => /c/WINDOWS/System32/IMM32.DLL (0x7ff96756) 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 (0x7ff968c3) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff967c1) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ff9663f) msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff968a7) libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x6144) libgeos-3.10.1.dll => /projects/geos/rel-3.10.1w64gcc81/bin/libgeos-3.10.1.dll (0x7020) libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll
Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
"Regina Obe" 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 (0x7ff966af) > 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
Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
> > 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 -- > > ERROR: could not load library > > "C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll": > > The specified module could not be found. > > 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 :) > That error doesn't show what couldn't be found, and I'd suggest the equivalent > of objdump and ldd. > > But seriously, that doesn't sound right. > > One issue is that the c library has a (on POSIX) DT_NEEDED for the C++, and > sometimes (libtool?) when building a program that links with libgeos_c, the > libraries that libgeos_c depend on are also added at DT_NEEDED to the > program. [Regina Obe] You solved the problem :) Ldd Shows this: ldd /projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll : ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ff966af) 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. 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. In GEOS 3.10.0 the c++ one was called: libgeos_c-1.dll Why is this ugly creature back? If it was to congeal the libtool / CMake worlds I guess I can learn to live with this ugliness. Thanks, Regina ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
"Regina Obe" writes: > I was always under the assumption that the C-API should be upward compatible > (only the C++ API is unstable). yes > Normally I can do the following: > > Compile PostGIS with GEOS say 3.9.0 > > Launch my PostgreSQL with GEOS 3.9.0 > > Then launch again with newer GEOS - in this case GEOS 3.11. That is not about API stability. It is about having the same ABI > 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? > What I am finding is it is not. I thought maybe I had the paths wrong so I > double-checked a couple of times. > > This is what I get when I swap out the older GEOS 3.9.0 with newer GEOS 3.11 > (main branch) > > And then run any PostGIS function. > > ERROR: could not load library > "C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll": > The specified module could not be found. Well, your real problem is that you are using windows! That error doesn't show what couldn't be found, and I'd suggest the equivalent of objdump and ldd. > I then tried to swap with GEOS 3.10.0 and that worked okay. > POSTGIS="3.2.0dev 3.2.0beta3-2-g0b32bdd14" [EXTENSION] PGSQL="140" > GEOS="3.10.0-CAPI-1.16.0" PROJ="7.2.1" GDAL="GDAL 3.3.3, released > 2021/10/25" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 > (Internal)" TOPOLOGY RASTER > > GEOS 3.10.1 - errors > ERROR: could not load library > "C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll": > The specified module could not be found. > > Can someone confirm that? If it's just an issue with PostGIS 3.2, I guess > that is okay, though I would think it would mean just the newer features > like MakeValid would not be enabled by swapping out with a newer GEOS, but > it shouldn't break install. Also why GEOS 3.10.0 works and GEOS 3.10.1 > doesn't is very concerning. But seriously, that doesn't sound right. One issue is that the c library has a (on POSIX) DT_NEEDED for the C++, and sometimes (libtool?) when building a program that links with libgeos_c, the libraries that libgeos_c depend on are also added at DT_NEEDED to the program. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
I was always under the assumption that the C-API should be upward compatible (only the C++ API is unstable). Normally I can do the following: Compile PostGIS with GEOS say 3.9.0 Launch my PostgreSQL with GEOS 3.9.0 Then launch again with newer GEOS - in this case GEOS 3.11. So my PostGIS is compiled with GEOS 3.9.0, but it should work with GEOS 3.11. What I am finding is it is not. I thought maybe I had the paths wrong so I double-checked a couple of times. This is what I get when I swap out the older GEOS 3.9.0 with newer GEOS 3.11 (main branch) And then run any PostGIS function. ERROR: could not load library "C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll": The specified module could not be found. I then tried to swap with GEOS 3.10.0 and that worked okay. POSTGIS="3.2.0dev 3.2.0beta3-2-g0b32bdd14" [EXTENSION] PGSQL="140" GEOS="3.10.0-CAPI-1.16.0" PROJ="7.2.1" GDAL="GDAL 3.3.3, released 2021/10/25" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" TOPOLOGY RASTER GEOS 3.10.1 - errors ERROR: could not load library "C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll": The specified module could not be found. Can someone confirm that? If it's just an issue with PostGIS 3.2, I guess that is okay, though I would think it would mean just the newer features like MakeValid would not be enabled by swapping out with a newer GEOS, but it shouldn't break install. Also why GEOS 3.10.0 works and GEOS 3.10.1 doesn't is very concerning. FWIW: all were built under CMake. Though I think the ENABLE_INLINE whatever that CMAKE switch is might be different between the working and non-working versions. Thanks, Regina ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
