[geos-devel] 3.12 release warning

[Paul Ramsey]

> On Jun 20, 2023, at 10:28 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> 
> 
>> On Jun 20, 2023, at 9:29 AM, Greg Troxel <gdt at lexort.com> wrote:
>> 
>> Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:
>> 
>>> Warning message:
>>> In fun(libname, pkgname) :
>>> rgeos: versions of GEOS runtime 3.12.0beta2-CAPI-1.18.0
>>> and GEOS at installation 3.11.1-CAPI-1.17.1differ
>> 
>> Also, I found that geoe does not use the just-built library when running
>> tests, due to inadequate RPATH/LD_LIBRARY_PATH, so if you are testing
>> 3.12 on a system with 3.11 installed, the tests may be running 3.11
>> code.
> 
> It would be helpful if this finding were qualified with the particular platform it was found on, and the steps to reproduce, since I’ve never managed to make it happen myself, and my computer is chock full of different versions of GEOS in different places.

So what I have found in MacOS and just now trying out ArchLinux is that we are getting the default cmake behaviour, which is to set the rpath to the absolute path to the build library directory. So for example, here’s the output for ArchLinux

readelf -d ./bin/geosop | head -20

  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libgeos_c.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libgeos.so.3.12.0]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/arch/geos/_build/lib]

And for MacOS

Load command 18
          cmd LC_RPATH
      cmdsize 56
         path /Users/pramsey/Code/geos-git/_build/lib (offset 12)

The internet concurs that this is the normal behaviour for cmake builds. 

With that runpath in place, I’ve never had a problem with builds getting confused when running testing. 

It is worth noting that on INSTALL, cmake will re-write the rpath for the installed binaries, so for example, after doing ‘make install’ on ArchLinux, the library info now has a path relative to ORIGIN.

readelf -d /usr/local/bin/geosop | head -20

Dynamic section at offset 0x75d50 contains 32 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libgeos_c.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libgeos.so.3.12.0]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib]

I can make the linker unhappy by doing a manual move of the build directory…

cd ..
mv _build _build2
cd _build2
./bin/geosop

Since the build rpath is absolute, the rpath no longer resolves, and yes, the binaries will resolve to linking any other geos it can find on linker path. Which if you have installed some other version or have an LD_LIBRARY_PATH set pointing to some other place, will result in you “testing” something other than the contents of your ./lib directory.

So, the build directory is “special”, and the library in the builddir/lib is not the same as one in installdir/lib
So, use an actual install to get an installed copy to test against, don’t manually move the build directory around and treat it as equivalent to an install, it is not.

P.


> 
> P
> 
> 
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/geos-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20230620/705f87e7/attachment-0001.htm>