From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, walther(at)technowledgy(dot)de, Christophe Pettus <xof(at)thebuild(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Date: | 2024-03-26 07:19:09 |
Message-ID: | 515199be-2f4d-4e47-9b6e-d3f3ed11e510@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 26.03.24 00:43, Tom Lane wrote:
> I wrote:
>> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
>>> I had originally proposed to avoid anything beginning "LD_" but Tom
>>> suggested being more specific. I doubt LD_PRELOAD can really hurt you
>>> though (the linker probably only needs the value at the start by
>>> definition, not at later dlopen() time (?)).
>
>> Oh, good point. So we could simplify the patch by only looking for
>> LD_LIBRARY_PATH.
>
> I looked at the musl source code you identified and confirmed that
> only the LD_LIBRARY_PATH string is remembered in a static variable;
> LD_PRELOAD is only accessed locally in that initialization function.
> So we only need to do the attached. (I failed to resist the
> temptation to rewrite the comments.)
Yeah, I was more looking for a comment for posterity for *why* we need
to preserve this variable in particular. The updated comment looks
reasonable.
From | Date | Subject | |
---|---|---|---|
Next Message | walther | 2024-03-26 07:36:40 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Previous Message | Peter Eisentraut | 2024-03-26 05:59:30 | Re: BUG #18407: ALTER TABLE SET SCHEMA on foreign table with SERIAL column does not move sequence to new schema |
From | Date | Subject | |
---|---|---|---|
Next Message | Yasuo Honda | 2024-03-26 07:21:46 | Re: pg_stat_statements and "IN" conditions |
Previous Message | Peter Eisentraut | 2024-03-26 07:14:46 | Re: Built-in CTYPE provider |