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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
