From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Gurjeet Singh <gurjeet(at)singh(dot)im>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: `make check` doesn't pass on MacOS Catalina |
Date: | 2022-08-06 15:25:09 |
Message-ID: | 12121.1659799509@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I came across this when I was working on setting up some Dockerfiles for
> the buildfarm. Apparently LD_LIBRARY_PATH doesn't work on Alpine, at
> least out of the box, as it uses a different linker, and "make check"
> relies on it (or the moral equivalent) if "make install" hasn't been run.
I did some quick googling on this point. We seem not to be the only
project having linking issues on Alpine, and yet it does support
LD_LIBRARY_PATH according to some fairly authoritative-looking pages, eg
https://www.musl-libc.org/doc/1.0.0/manual.html
I suspect the situation is similar to macOS, ie there is some limitation
somewhere on whether LD_LIBRARY_PATH gets passed through. If memory
serves, the problem on SIP-enabled Mac is that DYLD_LIBRARY_PATH is
cleared upon invoking bash, so that we lose it anywhere that "make"
invokes a shell to run a subprogram. (Hmm ... I wonder whether ninja
uses the shell ...) I don't personally care at all about Alpine, but
maybe somebody who does could dig a little harder and characterize
the problem there better.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-08-06 15:32:49 | Re: `make check` doesn't pass on MacOS Catalina |
Previous Message | Zhang Mingli | 2022-08-06 15:02:53 | Re: Allocator sizeof operand mismatch (src/backend/regex/regcomp.c) |