Re: pkgsrc on alpine linux (non-gnu userland) - trip report

[Michael Forney <mforney%mforney.org@localhost>]

On 2020-05-28, nia <nia%netbsd.org@localhost> wrote:
> recently set up an alpine linux in nvmm for cross compiling compilers for
> netbsd/amd64. decided to test pkgsrc on it.

Thanks for bringing this up. I've been doing something similar (pkgsrc
on linux-musl with non-GNU tools), and have a few more things to add
based on my experiences:

# MACHINE_GNU_PLATFORM

By default (on x86_64), pkgsrc sets this to x86_64-unknown-linux, and
config.sub from autoconf canonicalizes this as
x86_64-unknown-linux-gnu[0].

This is easy to work around in mk.conf, but I wonder what a proper fix
would look like. mk/platform/Linux.mk runs libc.so.6 to detect
GLIBC_VERSION, so maybe we could detect musl in a similar way.

[0] http://git.savannah.gnu.org/cgit/config.git/tree/config.sub?id=e78c96e5288993aaea3ec44e5c6ee755c668da79#n1396

# Builtin gettext and iconv detection

musl has built-in gettext and iconv that are part of libc. pkgsrc is
able to properly detect IS_BUILTIN.gettext since musl's libintl.h
defines __USE_GNU_GETTEXT. However, it is not able to detect
IS_BUILTIN.iconv. musl's iconv.h doesn't appear to contain any
identifying keywords, so I'm not sure how to fix this.

Some packages with older gettext.m4 (before [1]) use GNU gettext
internal symbols to detect gettext, which fails when not using GNU
gettext. pkgsrc's gettext builtin.mk sets configure cache variables to
prevent this, but it only does this for the case where libiconv is
separate from libc. I've been using the following diff to set the
corresponding cache variables when iconv is part of libc:

diff --git a/devel/gettext-lib/builtin.mk b/devel/gettext-lib/builtin.mk
index 1f42c7d777c..3769987ffb0 100644
--- a/devel/gettext-lib/builtin.mk
+++ b/devel/gettext-lib/builtin.mk
@@ -127,6 +127,13 @@ CONFIGURE_ENV+=
gt_cv_func_gnugettext1_libintl="yes"
            empty(H_NGETTEXT_GETTEXT:M${LOCALBASE}/*)
 CONFIGURE_ENV+=                gt_cv_func_gnugettext2_libintl="yes"
 .        endif
+.      else
+CONFIGURE_ENV+=                gt_cv_func_gnugettext_libc="yes"
+CONFIGURE_ENV+=                gt_cv_func_gnugettext1_libc="yes"
+.        if empty(H_NGETTEXT_GETTEXT:M__nonexistent__) && \
+           empty(H_NGETTEXT_GETTEXT:M${LOCALBASE}/*)
+CONFIGURE_ENV+=                gt_cv_func_gnugettext2_libc="yes"
+.        endif
 .      endif
 .    endif
 .  endif

[1] https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blobdiff;f=gettext-runtime/m4/gettext.m4;h=eef5073b32cbbb94d33cd34075cf12d6e2703f16;hp=1f6979a531dc107411c9e7819b3a97d8340dde5e;hb=b67399b40bc5bf3165b09e6a095ec941d4b30a97;hpb=34feee233ae4d66b2e1658159e5319ded111e97b

# lchmod

Linux does not have a way to set the mode of a symlink, so both glibc
and musl implement lchmod so that it returns EOPNOTSUPP when called
with a symlink. nbpax treats this as a fatal error, preventing
extraction of archives with symlinks. This works on glibc since
autoconf is able to detect the presence of __stub_lchmod and
libnbcompat replaces it with a version that returns 0 for symlinks.

Possible solutions:
- Ignore EOPNOTSUPP from lchmod in nbpax. lchmod(path, mode) can be
considered to be the same as fchmodat(AT_FDCWD, path, mode,
AT_SYMLINK_NO_FOLLOW), and POSIX explicitly allows this to fail with
EOPNOTSUPP on systems that don't have this functionality.
- On Linux, force ac_cv_func_lchmod=no in libnbcompat.

> - i was able to build rust-bin because it explicitly uses
>   the musl bins if glibc isn't detected. lang/rust should
>   probably do the same.

Unfortunately, the rust musl situation is a huge mess. When the
*-unknown-linux-musl targets were added to rust, they did so without a
native musl toolchain, and instead copy the musl libc.a into
liblibc.rlib and statically link everything by default. Even if you
set target-feature=-crt-static in RUSTFLAGS or ~/.cargo/config, these
do not apply for build scripts or procedural macros, so builds fail.
There is no way disable static linking for build scripts when --target
is passed to cargo (i.e. when building firefox).

As far as I understand, the default *-unknown-linux-musl is intended
for non-musl hosts to compile static binaries for use in containers,
and is not suitable for a musl-based host system. Based on comments in
various issues on github, it looks like they aren't willing to fix
this for backwards compatibility reasons. As a result, every musl
distribution has to patch rust to add their own triple name or change
the meaning of *-unknown-linux-musl.