[postgis-devel] [geos-devel] MacOS DYLD Fix

Paul Ramsey pramsey at cleverelephant.ca
Fri Nov 10 15:58:08 PST 2023


An exciting possibility, I haven’t poked that bear yet.

> On Nov 10, 2023, at 3:57 PM, Regina Obe <lr at pcorp.us> wrote:
> 
> Hmm what about GDAL built with GEOS on Mac, anything fun happen there? 
>  
> From: Paul Ramsey <pramsey at cleverelephant.ca> 
> Sent: Friday, November 10, 2023 6:51 PM
> To: Regina Obe <lr at pcorp.us>
> Cc: GEOS Development List <geos-devel at lists.osgeo.org>; PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: [geos-devel] MacOS DYLD Fix
>  
>  
> 
> 
>> On Nov 10, 2023, at 3:46 PM, Regina Obe <lr at pcorp.us <mailto:lr at 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 <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca>> 
>> Sent: Friday, November 10, 2023 12:58 PM
>> To: Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us>>
>> Cc: GEOS Development List <geos-devel at lists.osgeo.org <mailto:geos-devel at 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 <lr at pcorp.us <mailto:lr at pcorp.us>> wrote:
>>>  
>>> I’ll hold off on releasing until there is consensus on this issue.
>>>  
>>> From: geos-devel <geos-devel-bounces at lists.osgeo.org <mailto:geos-devel-bounces at 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 at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org>>
>>> Cc: Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20231110/85187100/attachment.htm>


More information about the postgis-devel mailing list