musl thoughts

["Andreas Müller" <schnitzeltony@gmail.com>]

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?

Andreas

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