Re: Regression tests fail with musl libc because libpq.so can't be loaded

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.

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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