pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Christophe Pettus <xof@thebuild.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Wolfgang Walther <walther@technowledgy.de>
Cc: PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded
Date: Mon, 18 Mar 2024 10:23:32 -0400
Message-ID: <3561573.1710771812@sss.pgh.pa.us> (raw)
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>

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





view thread (86+ messages)  latest in thread

Message-ID: <3561573.1710771812@sss.pgh.pa.us>
Permalink:  ../3561573.1710771812@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3561573.1710771812@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, xof@thebuild.com, andrew@dunslane.net, walther@technowledgy.de, pgsql-bugs@lists.postgresql.org
  Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded
  In-Reply-To: <3561573.1710771812@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox