> On Jun 8, 2023, at 8:42 AM, Greg Troxel <g...@lexort.com> wrote: > > Paul Ramsey <pram...@cleverelephant.ca> writes: > >>> On Jun 7, 2023, at 5:26 PM, Greg Troxel <g...@lexort.com> wrote: >>> >>> If I install the 3.12.0beta1 package, then the tests pass. So there is >>> a bug, but it is that the tests appaprently refer to installed files, >>> rather than being controlled to use only files in the build tree. >> >> We had this out last release, it’s specific to a particular OS. Happy to >> look over a cmake patch. >> >> https://lists.osgeo.org/pipermail/geos-devel/2022-June/010723.html > > I didn't remember anything from the last release... > > Are you saying that on every other OS, including some other BSD, that if > one has installed to a prefix not in the default search paths, and has > the old version installed, and runs the tests after building the new > version, that they succeed? I did not absorb that from reading the > archives.
This is what I’m saying, though I personally only sling MacOS and Linux regularly. You’re the only one I have heard complaints about our source tarballs from on this issue. > I am not particularly skilled at cmake, but I did find a note (that I > managed not to read this time) that the problem is misordering RPATH > args, so that the rpath passed in from a packaging system that says to > find any depending libs in $prefix/lib happens before the special test > rpath that says to get libs from something like builddir/lib. If that's > true, this isn't OS specific (and is a regression from the autotools > build). > > But I understand where you are coming from as ENOPATCH. Er, not sure what that means. If it means I think things are *mostly* fine, then yes. I’d like for you also to not have problems running build/check but I lack the visibility on the problem to attack it personally. P. _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
