| From: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | PostgreSQL Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
| Date: | 2024-03-16 20:21:55 |
| Message-ID: | 23205767-d108-40f0-9609-8381ab7a36fa@technowledgy.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Tom Lane:
> We have the same situation on macOS. There, it seems to be the result
> of a "security feature" that strips DYLD_LIBRARY_PATH from the process
> environment when make executes a shell.
I'm not sure whether this explanation is sufficient for the musl case,
because LD_LIBRARY_PATH does make a difference: The direct dependency
(libpqwalreceiver.so) can still be found if it's moved elsewhere and
LD_LIBRARY_PATH points at it. So clearly the LD_LIBRARY_PATH variable is
still set after make executed the shell - it's just not in effect on the
*indirect* dependency (libpq.so) anymore.
Best,
Wolfgang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Wolfgang Walther | 2024-03-16 20:31:10 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
| Previous Message | Thomas Munro | 2024-03-16 20:19:34 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2024-03-16 20:25:18 | Re: BitmapHeapScan streaming read user and prelim refactoring |
| Previous Message | Thomas Munro | 2024-03-16 20:19:34 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |