[OE-core] Should systemd be marked as incompatible with musl?
Adrian Bunk
bunk at stusta.de
Wed May 29 10:29:34 UTC 2019
On Wed, May 29, 2019 at 11:01:51AM +0200, Khem Raj wrote:
> On Wed, May 29, 2019 at 9:31 AM Adrian Bunk <bunk at stusta.de> wrote:
>...
> > And all these compile errors with musl due to header order are a real WTF,
> > every other library (not limited to C libraries) is now doing headers
> > properly so that any order works. No fun in supporting a broken design.
>
> I think these are concerns you must raise in musl community, OE is
> downstream where we can experiment but not fix these problems, thy
> should
> be fixed in repsective upstreams as much as possible
> upsttream might have answers or might benefit from this feedback
This doesn't work when the root cause is an intentional design decision
by upstream, and everyone bringing up such a topic again will just be
considered annoying.
Just like asking musl upstream for a __MUSL__ define would not be
successful, but would be required e.g. for making the musl patch
in webkitgtk upstreamable.
>...
> > > 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).
> >
> > I already tried patching musl in OE.
> > The change got reverted.
>
> Its costly to change fundamental APIs in libc which are not accepted
> upstream, especially in libc which will
> go into SDKs and will become default API set solely provided by
> OE thats a huge cost in time.
A macro in a header does not change the ABI or fundamental APIs.
> I suggested
> you to submit the patch upstream musl, I still encourage you to do so.
>...
This was a dead end - musl upstream thinks that software shouldn't
be doing "loop on EINTR".
At that point the only realistic options are to either patch
TEMP_FAILURE_RETRY once into musl, or to patch it into all
current and future users.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
More information about the Openembedded-core
mailing list