[geos-devel] 3.12.0beta1

[Paul Ramsey]

> On Jun 8, 2023, at 8:42 AM, Greg Troxel <gdt at lexort.com> wrote:
> 
> Paul Ramsey <pramsey at cleverelephant.ca> writes:
> 
>>> On Jun 7, 2023, at 5:26 PM, Greg Troxel <gdt at 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.