Re: `make check` doesn't pass on MacOS Catalina

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-08 14:56:21
Message-ID: 82b3ee80-3923-87db-3b3a-2329f3810093@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2022-08-06 Sa 12:10, Andrew Dunstan wrote:
> On 2022-08-06 Sa 11:25, Tom Lane wrote:
>> 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.
>>
>>
>
> We probably should care about Alpine, because it's a good distro to use
> as the basis for Docker images, being fairly secure, very small, and
> booting very fast.
>
> I'll dig some more, and possibly set up a (docker based) buildfarm instance.
>
>

It appears that LD_LIBRARY_PATH is supported on Alpine but it fails if
chained, which seems somewhat braindead. The regression tests get errors
like this:

+ERROR:  could not load library
"/app/buildroot/HEAD/pgsql.build/tmp_install/app/buildroot/HEAD/inst/lib/postgresql/libpqwalreceiver.so":
Error loading shared library libpq.so.5: No such file or directory
(needed by
/app/buildroot/HEAD/pgsql.build/tmp_install/app/buildroot/HEAD/inst/lib/postgresql/libpqwalreceiver.so)

If the check stage is delayed until after the install stage the tests pass.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcos Pegoraro 2022-08-08 15:07:59 Re: bug on log generation ?
Previous Message Peter Geoghegan 2022-08-08 14:51:51 Re: Remaining case where reltuples can become distorted across multiple VACUUM operations