On Sat, May 25, 2019 at 12:25 AM Adrian Bunk <[email protected]> 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). -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
