Re: Regression tests fail with musl libc because libpq.so can't be loaded
От | Bruce Momjian |
---|---|
Тема | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Дата | |
Msg-id | Zf3fnKpHIGpe5mOi@momjian.us обсуждение исходный текст |
Ответ на | Re: Regression tests fail with musl libc because libpq.so can't be loaded (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Regression tests fail with musl libc because libpq.so can't be loaded
Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Список | pgsql-bugs |
On Fri, Mar 22, 2024 at 09:36:19AM -0400, Bruce Momjian wrote: > On Fri, Mar 22, 2024 at 09:33:38AM +0100, walther@technowledgy.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. With no one "hoping this patch dies in a fire"*, I have updated it with more details, which I now think is committable to master. Is this something to backpatch? Seems too rare a bug to me. * Robert Haas, https://www.postgresql.org/message-id/CA%2BTgmoYsyrCNmg%2BYh6rgP7K8r-bYPjCeF1tPxENRFwD4VZAZvw%40mail.gmail.com -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Вложения
В списке pgsql-bugs по дате отправления: