Building with musl in CI and the build farm

From: Wolfgang Walther <walther(at)technowledgy(dot)de>
To: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Building with musl in CI and the build farm
Date: 2024-03-26 08:22:28
Message-ID: 0a48d551-50e1-4bd3-8d46-8421e3b1b724@technowledgy.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

The need to do $subject came up in [1]. Moving this to a separate
discussion on -hackers, because there are more issues to solve than just
the LD_LIBRARY_PATH problem.

Andres Freund:
> FWIW, except for one small issue, building postgres against musl works on
> debian and the tests pass if I install first.
>
>
> The small problem mentioned above is that on debian linux/fs.h isn't available
> when building with musl, which in turn causes src/bin/pg_upgrade/file.c to
> fail to compile. I assume that's not the case on "fully musl" distro?

Correct, I have not seen this before on Alpine.

Here is my progress setting up a buildfarm animal to run on Alpine Linux
and the issues I found, so far:

The animal runs in a docker container via GitHub Actions in [2]. Right
now it's still running with --test, until I get the credentials to
activate it.

I tried to enable everything (except systemd, because Alpine doesn't
have it) and run all tests. The LDAP tests are failing right now, but
that is likely something that I need to fix in the Dockerfile - it's
failing to start the slapd, IIRC. There are other issues, though - all
of them have open pull requests in that repo [3].

I also had to skip the recovery check. Andrew mentioned that he had to
do that, too, when he was still running his animal on Alpine. Not sure
what this is about, yet.

Building --with-icu fails two tests. One of them (001_initdb) is fixed
by having the "locale" command in your PATH, which is not the case on
Alpine by default. I assume this will not break on your debian/musl
build, Andres - but it will also probably not return any sane values,
because it will run glibc's locale command.
I haven't looked into that in detail, yet, but I think the other test
(icu/010_database) fails because it expects that setlocale(LC_COLLATE,
<illegal_value>) throws an error. I think it doesn't do that on musl,
because LC_COLLATE is not implemented.
Those failing tests are not "just failing", but probably mean that we
need to do something about how we deal with locale/setlocale on musl.

The last failure is about building --with-nls. This fails with something
like:

ld: src/port/strerror.c:72:(.text+0x2d8): undefined reference to
`libintl_gettext'

Of course, gettext-dev is installed, libintl.so is available in /usr/lib
and it also contains the symbol. So not sure what's happening here.

Andres, did you build --with-icu and/or --with-nls on debian/musl? Did
you run the recovery tests?

Best,

Wolfgang

[1]:
https://postgr.es/m/fddd1cd6-dc16-40a2-9eb5-d7fef2101488%40technowledgy.de
[2]:
https://github.com/technowledgy/postgresql-buildfarm-alpine/actions/workflows/run.yaml
[3]: https://github.com/technowledgy/postgresql-buildfarm-alpine/pulls

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Francisco Olarte 2024-03-26 09:55:13 Re: BUG #18408: ERROR: could not load library
Previous Message walther 2024-03-26 07:43:54 Re: Regression tests fail with musl libc because libpq.so can't be loaded

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2024-03-26 08:24:00 Re: Introduce XID age and inactive timeout based replication slot invalidation
Previous Message Masahiko Sawada 2024-03-26 08:16:10 Re: Add new error_action COPY ON_ERROR "log"