Re: musl thoughts

[Mark Hatle <mark.hatle@windriver.com>]

On 3/21/19 8: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
> 
> 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?

I'm late jumping into this.. but for things that may not build due to inherent
expectations from glibc...  you could just block the package if "not-glibc" is
enabled.

You could do this something like:

BLACKLISTMSG = "This package only works with glibc."
BLACKLISTMSG_libc-glibc = ""

PNBLACKLIST[${PN}] = "${BLACKLISTMSG}"

(I'm sure there is a cleaner way -- but the point is, if the package says sorry
-- I don't work with musl -- that is much more preferable to bitbake parses,
unpacks, patches, starts to build and explodes with no explanation...)

--Mark

> Andreas
> 
> [1] http://lists.openembedded.org/pipermail/openembedded-devel/2018-March/193521.html
>