<div dir="ltr"><br><br>On Sat, Oct 2, 2021 at 4:07 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br>><br>> > Also, the tests are broken for me.   Running make check fails<br><div>> > completely, and I find in the log:</div><div><br></div><div>Everything works fine in MacOS, I don't have access to a broken platform to try things out on...</div><div><br></div><div>Sparrow:~/Code/geos-git-build pramsey% otool -L bin/test_geos_unit <br>bin/test_geos_unit:<br>    @rpath/libgeos_c.1.dylib (compatibility version 1.0.0, current version 1.16.0)<br>        @rpath/libgeos.3.10.0.dylib (compatibility version 3.10.0, current version 3.10.0)<br>    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)<br>        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)</div><div><br></div><div>The file diffs all look reasonable to me. Some classes were added, a few were removed.</div><div><br></div><div>I'm looking at the pthreads thing... there are a few tests that do multi-threaded things to test the reentrant code bits, but the library itself doesn't use pthreads. I'm trying to figure if/how to make sure we aren't having it as a library dependency, it should only be a unit test dependency.</div><div><br></div><div>P<br></div><div><br></div>> ><br>> > /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit: Shared object "libgeos.so.3.10.0" not found<br>> ><br>> > I am running tests from the build directory before I have built a<br>> > package  and then replaced the existing 3.9 installation.  So in<br>> > /usr/pkg/lib, where the library is expected to be, there is<br>> > libgeos.so.3.9.0 and no 3.10.  Looking at the test program:<br>> ><br>> > $ ldd /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit<br>> > /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit:<br>> >         -lgeos_c.1 => /usr/pkg/lib/libgeos_c.so.1<br>> >         -lgeos-3.9.1 => /usr/pkg/lib/<a href="http://libgeos-3.9.1.so">libgeos-3.9.1.so</a><br>> >         -lstdc++.9 => /usr/lib/libstdc++.so.9<br>> >         -lm.0 => /usr/lib/libm.so.0<br>> >         -lc.12 => /usr/lib/libc.so.12<br>> >         -lgcc_s.1 => /usr/lib/libgcc_s.so.1<br>> >         -lgeos.3.10.0 => not found<br>> >         -lpthread.1 => /usr/lib/libpthread.so.1<br>> ><br>> > I see it's also finding the wrong libgeos_c, so the root cause is very<br>> > likely not arranging a temporary library path for testing built but not<br>> > installed code.  autoconf/libtool did this correctly, with a scheme to<br>> > link test programs (and anything else) against the built but not<br>> > installed library, and then to relink at installation.  There are of<br>> > course multiple approaches, but "make check" needs to use the<br>> > programs/libs in the build tree, and ignore what's installed.<br>><br>> I worked around the bug in "make check" by installing the package, and<br>> then building it again and running tests, so that when it links against<br>> the wrong library, it finds the same bits.   I was happy to see that all<br>> the tests passed, so there aren't any real geos bugs, just cmake/test<br>> bugs.</div>