All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.