From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Christophe Pettus <xof@thebuild.com>,
 Andrew Dunstan <andrew@dunslane.net>,
        Wolfgang Walther <walther@technowledgy.de>,
        PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>
Subject: Re: Regression tests fail with musl libc because libpq.so can't be
 loaded
In-reply-to: 
 <CA+hUKGJW_ht0VYsr7bzF8-FLZW_o3Ys6Xm5w10GU5WBHtfv+zg@mail.gmail.com>
References: <fddd1cd6-dc16-40a2-9eb5-d7fef2101488@technowledgy.de>
 <2852940.1710599083@sss.pgh.pa.us>
 <443da167-ee01-47d2-9c83-105694b4cbd5@technowledgy.de>
 <CA+hUKGJhp0opkCybdOrbQSMyHX8cRuLh2ygkqtivizCqK6kfOA@mail.gmail.com>
 <CA+hUKGL=CE7Gg5p7ijbtEWhnPR-Ua4gemhuz-kQpSy3dD1+SYQ@mail.gmail.com>
 <ef1b47df-0808-4bd7-b08c-5153d5d75f4c@technowledgy.de>
 <68C88EE3-CDCB-4993-9173-3A773F491F3A@thebuild.com>
 <855a1b16-0dc0-42b2-8f90-79eb49cf2893@technowledgy.de>
 <F5A214FF-1BED-4935-B4FF-4679CCF463D6@thebuild.com>
 <CAD5tBcLWM+QT0+VKWUHiBX2Ey5eCc8jVL5APb1U5iaePV_eAvg@mail.gmail.com>
 <A9F65857-A286-4EB8-96CE-EA5C1636A05C@thebuild.com>
 <CA+hUKG+H80zJTmNnRbAQb+py2xpzNUtmoacbfnyAi2c5d1imGg@mail.gmail.com>
 <E5D4E3AE-C926-48C5-84DC-57E3E9357675@thebuild.com>
 <CA+hUKGJW_ht0VYsr7bzF8-FLZW_o3Ys6Xm5w10GU5WBHtfv+zg@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Tue, 19 Mar 2024 02:25:33 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3561572.1710771812.1@sss.pgh.pa.us>
Date: Mon, 18 Mar 2024 10:23:32 -0400
Message-ID: <3561573.1710771812@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3561573.1710771812%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> (Hmm, I think it's not that unreasonable on their part to assume the
> initial environment is immutable if their implementation doesn't
> mutate it, and our doing so is undeniably UB; surprising, maybe, given
> that the technique works on that other popular brand of C library on
> that kind of kernel, not to mention dozens of old Unixen of yore...

Does their implementation also ignore the effects of putenv() or
setenv() on LD_LIBRARY_PATH?  They have no moral high ground
whatsoever if that's the case.  But if it doesn't, an alternative
route to a solution could be to scan the original environment, strdup
and putenv each entry to move it to freshly malloc'd space, and
then reclaim the old environment area.

			regards, tom lane