An exciting possibility, I haven’t poked that bear yet. > On Nov 10, 2023, at 3:57 PM, Regina Obe <l...@pcorp.us> wrote: > > Hmm what about GDAL built with GEOS on Mac, anything fun happen there? > > From: Paul Ramsey <pram...@cleverelephant.ca> > Sent: Friday, November 10, 2023 6:51 PM > To: Regina Obe <l...@pcorp.us> > Cc: GEOS Development List <geos-devel@lists.osgeo.org>; PostGIS Development > Discussion <postgis-de...@lists.osgeo.org> > Subject: Re: [geos-devel] MacOS DYLD Fix > > > > >> On Nov 10, 2023, at 3:46 PM, Regina Obe <l...@pcorp.us >> <mailto:l...@pcorp.us>> wrote: >> >> This isn’t an issue with other projects besides PostGIS that use GEOS? >> Perhaps related, how much trouble would it be to get PostGIS to use >> pkgconfig for GEOS. I see that GEOS does ship pkgconfig files. > > We could probably do it on a going-forward basis, but per usual we’d end up > with all the old code *plus* the pkgconfig code, so it wouldn’t really “clean > up” anything. There are autoconf macros already in configure.ac doing > pkgconfig stuff on other deps, so not too too hard of an add. > > >> It’s always annoying when I try to do it that I have to explicitly specify >> the geos-config file in PostGIS when in other cases, we can read the >> pkg-config and have in fact standardized on that for other dependencies we >> use. >> >> I’ve added PostGIS dev to this since well we seem to be talking about >> PostGIS now. > > I’m honestly at a bit of a loss as to whether installing with an rpath and > expecting linking software to set an appropriate search path is the right > thing, or locking in a fixed installation location is the right thing. > Certainly the latter results in less nonsense in the postgis build. But it > broke proj, which had some tests that expected to be able to manually move an > installation post-install. > > P > > >> >> From: Paul Ramsey <pram...@cleverelephant.ca >> <mailto:pram...@cleverelephant.ca>> >> Sent: Friday, November 10, 2023 12:58 PM >> To: Regina Obe <l...@pcorp.us <mailto:l...@pcorp.us>> >> Cc: GEOS Development List <geos-devel@lists.osgeo.org >> <mailto:geos-devel@lists.osgeo.org>> >> Subject: Re: [geos-devel] MacOS DYLD Fix >> >> I’m on both sides of the argument now. The best/better practice might be to >> leave the install behaviour as-is and try to coerce PostGIS into ensuring >> the LD_RPATH on postgis.so, and other targets is set to the discovered >> locations of the dylib files in the ./configure. >> >> P. >> >> >> >>> On Nov 9, 2023, at 6:38 PM, Regina Obe <l...@pcorp.us >>> <mailto:l...@pcorp.us>> wrote: >>> >>> I’ll hold off on releasing until there is consensus on this issue. >>> >>> From: geos-devel <geos-devel-boun...@lists.osgeo.org >>> <mailto:geos-devel-boun...@lists.osgeo.org>> On Behalf Of Paul Ramsey via >>> geos-devel >>> Sent: Thursday, November 9, 2023 4:47 PM >>> To: GEOS Development List <geos-devel@lists.osgeo.org >>> <mailto:geos-devel@lists.osgeo.org>> >>> Cc: Paul Ramsey <pram...@cleverelephant.ca >>> <mailto:pram...@cleverelephant.ca>> >>> Subject: [geos-devel] MacOS DYLD Fix >>> >>> From XCode 15, the dyld linker no longer falls back to /usr/local/lib when >>> resolving an @rpath, so installing libraries in /usr/local/lib and hoping >>> that the linker finds them there is no longer workable. They need to be >>> installed with LC_ID_DYLIB set to the install location, which in cmake >>> world means installing them after setting the INSTALL_NAME_DIR property on >>> the target. >>> >>> https://github.com/libgeos/geos/commit/8cf761b4d77b1261e0f6673c6716adb2daee7eb1 >>> >>> I have committed this into main, and would like to pull it back a few >>> stable braches too, since I need it to effectively work on postgis/geos on >>> my Macbook, but I am going to hold off on the stable branches for a while, >>> if anyone working on main finds that this change has broken something in >>> *their* environment, please let me know. >>> >>> P.
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel