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

Reply via email to