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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: walther(at)technowledgy(dot)de
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Christophe Pettus <xof(at)thebuild(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded
Date: 2024-03-22 13:36:19
Message-ID: Zf2JU0_GDdbeBm5j@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Fri, Mar 22, 2024 at 09:33:38AM +0100, walther(at)technowledgy(dot)de wrote:
> Bruce Momjian:
> > I suggest we use the #ifdef test to continue our existing behavior for
> > the libraries we know about, like glibc, and use the LD_* process title
> > truncation hack for libc's we don't recognize.
> >
> > Attached is a prototype patch which implements this based on previous
> > patches.
>
> The condition to check for linux/glibc in your patch is slightly off:
>
> #if ! defined(__linux__) || (! defined(__GLIBC__) && defined(__UCLIBC__ ))
>
> should be
>
> #if defined(__linux__) && ! (defined(__GLIBC__) || defined(__UCLIBC__ ))
>
> With the latter, it passes tests with musl.

Yes, my logic was wrong. Not sure what I was thinking, frankly.

I am not a big fan of negating a complex conditional, but would rather
pass the negation into the conditional, new patch attached.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

Attachment Content-Type Size
proctitle.diff text/x-diff 1.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Janne Annala 2024-03-22 16:59:37 NEW.* and OLD.* inside trigger function don't seem to contain recently added columns
Previous Message PG Bug reporting form 2024-03-22 13:00:01 BUG #18404: Select from pg_stat_activity in a plpgsql block can lead to a global locking issue

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Prokhorenko 2024-03-22 13:42:20 Re: UUID v7
Previous Message Peter Eisentraut 2024-03-22 13:35:47 Re: documentation structure