Re: Building with musl in CI and the build farm

Here's an update on the progress to run musl (Alpine Linux) in the
buildfarm.

Wolfgang Walther:
> 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.

The animals have been activated and are reporting now. Thanks, Andrew!

> 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].

ldap tests are enabled, just a missing package.

> 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.

This was about a missing init process in the docker image. Without an
init process reaping zombie processes, the recovery tests end up with
some supposed-to-be-terminated backends still running and can't start
them up again. Fixed by adding a minimal init process with "tinit".

> 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.

I still need to look into this in depth.

> 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.

This is an Alpine Linux packaging issue. Theoretically, it could be made
to work by introducing some configure/meson flag like "--with-gettext"
or so, to prefer gettext's libintl over the libc-builtin. However, NixOS
/ nixpkgs with its pkgsMusl overlay manages to solve this issue just
fine, builds with --enable-nls and gettext work. Thus, I conclude this
is best solved upstream in Alpine Linux.

TLDR: The only real issue which is still open from PostgreSQL's side is
around locales and ICU - certainly the pain point in musl. Will look
into it further.

Best,

Wolfgang