From: Adrian Bunk <bunk@stusta.de>
To: Khem Raj <raj.khem@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: Should systemd be marked as incompatible with musl?
Date: Wed, 29 May 2019 13:29:34 +0300 [thread overview]
Message-ID: <20190529102934.GA13958@localhost> (raw)
In-Reply-To: <CAMKF1sp8tzV=5y8p=s4A0gwH4NpaW7MDF-Gbbon-QrUJrbgChw@mail.gmail.com>
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@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
next prev parent reply other threads:[~2019-05-29 10:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 10:33 Should systemd be marked as incompatible with musl? Adrian Bunk
2019-05-23 12:22 ` Burton, Ross
2019-05-24 1:45 ` ChenQi
2019-05-24 2:16 ` Khem Raj
2019-05-24 10:12 ` Adrian Bunk
2019-05-24 16:13 ` Khem Raj
2019-05-24 17:27 ` Adrian Bunk
2019-05-24 17:31 ` Khem Raj
2019-05-24 17:58 ` Adrian Bunk
2019-05-24 18:04 ` Khem Raj
2019-05-24 18:45 ` Adrian Bunk
2019-05-24 19:34 ` Andre McCurdy
2019-05-24 19:47 ` Khem Raj
2019-05-24 20:28 ` Adrian Bunk
2019-05-24 22:25 ` Andre McCurdy
2019-05-25 7:25 ` Adrian Bunk
2019-05-28 23:10 ` Andre McCurdy
2019-05-29 7:31 ` Adrian Bunk
2019-05-29 9:01 ` Khem Raj
2019-05-29 10:29 ` Adrian Bunk [this message]
2019-05-29 19:04 ` Andre McCurdy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190529102934.GA13958@localhost \
--to=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.