Re: musl thoughts

[akuster808 <akuster808@gmail.com>]

On 3/21/19 6:11 PM, Andreas Müller wrote:
> Just prepared meta-networking/networkmanager update and spent hours to
> get musl patches applied. Have no idea if musl will build and
> currently all my machines are building.
>
> For me - not using musl and looking forward to have a beer with Khem
> explaining me why I should want musl [1] - it is just useless effort
> and patches are rejected often due to failures on musl build.
>
> So on my way home I though about the options I see to handle musl specifics:
>
> 1. Continue as we do - patch recipe-wise: This is lots of efforts and
> requires resources we don't have. Most patches are created by Khem and
> it would be better for all of us to save his time for other tasks.
> 2. Sending musl related patches upstream: Surely the cleanest approach
> but even more effort because upstream maintainers all have different
> thoughts. Some of them might hear of musl for the first time and are
> possibly not keen on patches they do not see a need for.
> 3. Change our musl slightly: Many patches we currently have are
> trivial. Missing headers or #defines for missing functions... So if we
> add few headers
>   * Empty chunks for e.g <net/ethernet.h>
>   * Add defines as #define strndupa(x,s) strncpy(alloca(strlen(x)+1),x,s)
>   * ...
>
> As you might guess I'd prefer 3 because:
> + Many patches can go and don't need maintenance on upstream refactoring anymore
> + Burden for people sending patches would be reduced
> + Recipes not building with musl currently might work without further
> modification
> + Just in case musl stops (we have seen this before with others e.g
> ulibc) the cleanup would be reduced

Didn't we do something like this with glibc? We carried several patches
that where rejected and just recently got removed so there is a
precedent for carrying OE specific changes  so it seems like a
reasonable approach.

- armin
>
> Of course there are disadvantages:
> - We turn musl into glibc direction. Posix-purists do not like that.
> - Configuration scripts already aware of musl and deciding upon the
> existence of headers missing in musl might do the wrong thing
> - ?
>
> Some other ideas?
>
> Andreas
>
> [1] http://lists.openembedded.org/pipermail/openembedded-devel/2018-March/193521.html