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