Originally posted by Nozo
View Post
There are patches in openembedded that make systemd work with musl.
When you start looking at those patches you under stand the 2018 response at Systemd.
Particularly when you see
+#ifndef __GLIBC__
Yes worse the FTW_CONTINUE is a GCC provided thing that missing.
Notice that the FTW_CONTINUE is not inside the #ifndef __GLIBC__ so lets say there glibc header that provides FTW_CONTINUE has been deleted this patch now masks the issue. Next we don't expect that FTW_CONTINUE define as 0 by glibc will change to some other value but if it does you have just planted a land mine.
Yes using #ifndef __GLIBC__ basically says all libc that are not glibc will be missing this feature... Do you have a crystal ball.
This here covers the problem with Musl. There is no #ifdef__MUSL__ you cannot find out the MUSL version by C macro or by a runtime function.
So this is more not when will systemd support Musl but when will Musl grow up and add the features that at build time we can detect that we are building for a Musl system and enable required quirks without disrupting anything else so allowing clean targeted work around patches for Musl to be added to systemd.
The Musl theory of not providing a __MUSL__ is that all bugs should be fixed in upstream __MUSL__ now this brings a good question why in heck if this is the rule is custom work around patches being added to systemd instead of fixing Musl itself. Yes if this rule is obeyed it should not be when will systemd support musl but when will Musl support systemd.
Musl is a very deep rabbit hole of problems caused by this simple choice not to provide ___MUSL__ macro.
Comment