Message-ID: <23205767-d108-40f0-9609-8381ab7a36fa@technowledgy.de>
Date: Sat, 16 Mar 2024 21:21:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Wolfgang Walther <walther@technowledgy.de>
Subject: Re: Regression tests fail with musl libc because libpq.so can't be
 loaded
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>
Cc: PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>
References: <fddd1cd6-dc16-40a2-9eb5-d7fef2101488@technowledgy.de>
 <2852940.1710599083@sss.pgh.pa.us>
 <443da167-ee01-47d2-9c83-105694b4cbd5@technowledgy.de>
 <CAD5tBcJ7r_g1gUCp63ugjE6doz_Fu_1VJQJ5Cz_gLGKJ3e1Ktg@mail.gmail.com>
 <3005969.1710619856@sss.pgh.pa.us>
In-Reply-To: <3005969.1710619856@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/23205767-d108-40f0-9609-8381ab7a36fa%40technowledgy.de>
Precedence: bulk

Tom Lane:
> We have the same situation on macOS.  There, it seems to be the result
> of a "security feature" that strips DYLD_LIBRARY_PATH from the process
> environment when make executes a shell.

I'm not sure whether this explanation is sufficient for the musl case, 
because LD_LIBRARY_PATH does make a difference: The direct dependency 
(libpqwalreceiver.so) can still be found if it's moved elsewhere and 
LD_LIBRARY_PATH points at it. So clearly the LD_LIBRARY_PATH variable is 
still set after make executed the shell - it's just not in effect on the 
*indirect* dependency (libpq.so) anymore.

Best,

Wolfgang