"Regina Obe" <l...@pcorp.us> 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 (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) 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 (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 I'm having a Seventh Edition flashback :-) symlinks showed up in Eighth Edition, and probably in 2.8BSD. But if that's what you have to do, seems like the thing to do. >> > If it was to congeal the libtool / CMake worlds I guess I can learn to >> > live with this ugliness. I don't think it is about the libtool/cmake world, I think it is about conforming to expectations for shared library major version naming on Windows, to achieve some degree of soundness. As I understand it, the only real change from libtool/cmake on POSIX was to drop the libtool metadata files like libgeos.la. >> 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 You are delighted but I am horrifed at the apparent lack of soundness. > 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. > 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? > 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. But with proper shlib versioning they just sit there. It sounds like you are doing things without a packaging system, that packaging systems are intended to deal with. > 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 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).
signature.asc
Description: PGP signature
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
