macOS SIP, next try - Mailing list pgsql-hackers

From Peter Eisentraut
Subject macOS SIP, next try
Date
Msg-id ecec88aa-c982-a473-1b0f-cea596d405cf@enterprisedb.com
Whole thread Raw
Responses Re: macOS SIP, next try
Re: macOS SIP, next try
List pgsql-hackers
Previous discussions on macOS SIP:

https://www.postgresql.org/message-id/flat/561E73AB.8060800%40gmx.net
https://www.postgresql.org/message-id/flat/CA%2BTgmoYGi5oR8Rvb2-SY1_WEjd76H5gCqSukxFQ66qR7MewWAQ%40mail.gmail.com
https://www.postgresql.org/message-id/flat/6a4d6124-41f0-756b-0811-c5c5def7ef4b%402ndquadrant.com

Tests that use a temporary installation (i.e., make check) use a 
platform-specific environment variable to make programs and libraries 
find shared libraries in the temporary installation rather than in the 
actual configured installation target directory.  On macOS, this is 
DYLD_LIBRARY_PATH.  Ever since System Integrity Protection (SIP) 
arrived, this hasn't worked anymore, because DYLD_LIBRARY_PATH gets 
disabled by the system (in somewhat obscure ways).  The workaround was 
to either disable SIP or to do make install before make check.

The solution here is to use install_name_tool to edit the shared library 
path in the binaries (programs and libraries) after installation into 
the temporary prefix.

The solution is, I think, correct in principle, but the implementation 
is hackish, since it hardcodes the names and versions of the interesting 
shared libraries in an unprincipled way.  More refinement is needed 
here.  Ideas welcome.

In order to allow all that, we need to link everything with the option 
-headerpad_max_install_names so that there is enough room in the 
binaries to put in the temporary path in place of the original one. 
(The temporary path is strictly longer than the original one.)  This 
bloats the binaries, so it might only be appropriate for development 
builds and should perhaps be hidden behind some option.  Ideas also 
welcome here.

The attached patch works for me.  You can see that it disables setting 
DYLD_LIBRARY_PATH, but the tests still work.  Verification on other 
system variantions welcome, of course.

Comments welcome.  I think this direction is promising, but some details 
need to be addressed.

Attachment

pgsql-hackers by date:

Previous
From: Nikolay Samokhvalov
Date:
Subject: Re: pg_stat_statements oddity with track = all
Next
From: Chapman Flack
Date:
Subject: Re: proposal: unescape_text function