[OE-core] Should systemd be marked as incompatible with musl?

[Andre McCurdy]

On Sat, May 25, 2019 at 12:25 AM Adrian Bunk <bunk at stusta.de> wrote:
>
> Is there development capacity to support musl?

It would be shame if there wasn't enough developer capacity to support
musl but in the end it comes down to what contributors to OE want to
work on.

There's a danger that the areas which OE contributors want to work on
don't exactly match what the overall Embedded Linux community wants
and we alienate potential users (for example we ditched uClibc support
not because no one wants to use uClibc any more but because no
contributors to OE wanted to spend time on uClibc) but overall the
model seems to work OK. I think right now we have enough interest in
musl to keep it alive.

> Supporting musl is a real pain across the board,
> with new issues all the time.

There are always new issues and bugs to be solved in OE as a
consequence of trying to keep all packages up to date. Whether the
issues arising from musl are a real pain or a fun new set of problems
to solve is mostly a matter of perspective.

> For really tiny systems you need both a tiny C library and a tiny init> system, so not properly supporting the combination of both forces users
> to use alternative options instead of OE.
>
> Which minimizes the benefits gained by the pains of supporting musl.

A modern tiny init system would be nice to have, but it's not
essential or fair to say that musl is useless without one. Many
projects, especially tiny ones, manage fine with init scripts and
custom process management.

> > It's certainly a problem and we should try to fix it. It's not at all
> > uncommon that patches to fix build issues with musl, clang, a new
> > version of gcc, etc have a life cycle... a first pass just to fix the
> > build and then updates as issues are found or better solutions get
> > merged upstream. It's the normal process. You could argue that we are
> > sometimes too quick to merge the first pass hacks and too slow to
> > review and update them, but unfortunately that's just a consequence of
> > limited developer resources (and it's always more fun to try to get
> > the latest version of something working than review and cleanup old
> > patches...).
>
> If upstreaming is possible at all.
>
> With systemd on musl there is also the fundamental problem that
> neither of the upstreams is interested in compromising their
> software for the other.
>
> Not to blame either of them, there is simply a fundamental conflict
> between the systemd "use all functionality available" and the musl
> "be a tiny C library" and "follow standards and provide only some
> GNU extensions".
>
> One example:
>
> systemd uses qsort_r.
> musl upstream doesn't want to add qsort_r since it is nonstandard
> and BSD and glibc ended up providing incompatible versions.
> Most C libraries for Linux just follow glibc on that,
> but musl upstream is not doing this with a reasonable
> technical justification.
>
> For 0002-don-t-use-glibc-specific-qsort_r.patch (which looks as if it
> does cause data corruption) upstream is therefore in practice POSIX,
> unless you manage to convince systemd upstream to use something like
> gnulib to provide all the functionality they use that is not provided
> by musl. Which would also be a constant effort you have to makes since
> systemd upstream would not care about musl when making changes to
> their code.
>
> Even harder are cases like on_exit(3) (not currently hit by systemd but
> by other Linux-only software), which might not be implementable as an
> external function outside the C library.

Upstreamable solutions should always be preferred but if you can
accept that OE may need to carry patches which will never be
upstreamed (which isn't too much of a stretch given the age of some of
the patches we carry for gcc, busybox, etc) then none of the currently
known issues with systemd and musl seem like fundamental problems. A
few pragmatic patches applied by OE would go a long way to bridging
the conflicting goals of the two upstream projects. It's basically the
approach we've taken already - the question is just one of improving
the patches we already have (and maybe patching musl to add missing
functionality instead of only trying to patch systemd to not depend on
it).