> On Jun 20, 2023, at 10:28 AM, Paul Ramsey <pram...@cleverelephant.ca> wrote:
>
>
>
>> On Jun 20, 2023, at 9:29 AM, Greg Troxel <g...@lexort.com> wrote:
>>
>> Sebastiaan Couwenberg <sebas...@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@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
