Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of > Paul Ramsey > Sent: Monday, December 6, 2021 8:41 PM > To: GEOS Development List > Subject: Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS > 3.9.0 > > Semi worthless data point on this, but I did want to verify that everything still > worked at least for me, so I built against GEOS 3.6 and then swapped in > everything from 3.6 to main at runtime, and it all worked fine. > > P [Regina Obe] What are your libraries called? Did the names stay the same? In case you got lost in my long rant. Greg suggested looking at ldd and ldd showed the culprit. I suspect it might just be a windows issue, possibly even mingw64 cmake issue. The issue is the file names changed in my cmake builds between 3.10.0 to 3.10.1 So my 3.10.0 build had these files (and all versions I have built, including GEOS 3.6 have had these names). The fact they never changed made me happy (and I kept my mouth shut at the beauty of this bug). c-api => libgeos_c.dll c++ api -> libgeos.dll and from 3.10.1 forward, my files look like yuck: c-api => libgeos_c-1.dll c++ api -> libgeos-3.10.1.dll One can rightfully argue, that the old 3.10.0 behavior was a bug (I call it feature or a beautiful bug :) ) And that 3.10.1 is the proper way to version since the c++ abi is unstable it should be changing in each micro-release. I'm just a bit irritated this changed happened in a micro-release. Not a huge deal. 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
Semi worthless data point on this, but I did want to verify that everything still worked at least for me, so I built against GEOS 3.6 and then swapped in everything from 3.6 to main at runtime, and it all worked fine. P ___ 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 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//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 ___ 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: > 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/cofigs.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. On UNIX/ELF, I don't think shared library resolution is affected by PATH. But LD_LIBRARY_PATH yes. I'll simply accept that whatever env var setup you have on windows causes shlib resolution to look in alternate places; that's pretty clearly not the problem. > 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 I am unfamiliar with Windows DLL naming culture. Setting aside macOS as mutant, ~all POSIX/ELF systems normally name shared libraries as libfoo.so.A.B.C A is major (or ABI breaks) B is minor (for new interfaces) C is micro (for bugfixes) On my system, shp2pgsql has NEEDED libgeos_c.so.1" because that is the ABI version it was built with. And there is a symlink with that name 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 This allows the older ABI to be still present (such as on base system upgrades) and programs using the older ABI to find the version they need and work. It may be normal in windows not to do this, and I don't know if there if the shlib version is internal and if it is chdcked when dynamic linking. If it's not checked, this naming scheme is basically unsound. > 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) So that finds the 3.10.0 you have pointed it to, and it's not clear there is ABI version checking. > 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). Ah, so now I get the -1. Is this the normal way in windows to encode the shared library version in the file? In the C++ one, is "3.10.1" a string which is the shared library major version? (I am not 100% sure that there aren't ABI breaks in libgeos.3.9.0 to libgeos-3.10.0, but as in theory nothing else loads that it doesn't matter.) If this is the windows way to have the equivalent of libgeos_c.so.1, then it seems like it is the right thing. Someday, we might need to have an ABI break in libgeos_c, even though it's been avoided so far, and that would necessitate libgeos_c.so.2. > $ 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 =>
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
