[OE-core] musl thoughts

Mon Mar 25 22:38:12 UTC 2019

On Mon, Mar 25, 2019 at 2:12 PM Andreas Müller <schnitzeltony at gmail.com>
wrote:

> On Mon, Mar 25, 2019 at 6:46 PM Adrian Bunk <bunk at stusta.de> wrote:
> >
> > On Mon, Mar 25, 2019 at 06:15:40PM +0100, Andreas Müller wrote:
> > >...
> > > Looked into this. Found an old musl build failure of networkmanager
> > > [1] but I think the issue has not changed:
> > >
> > > | In file included from
> > >
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/net/ethernet.h:10,
> > > |                  from
> ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:28:
> > > |
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/netinet/if_ether.h:111:8:
> > > error: redefinition of 'struct ethhdr'
> > > |  struct ethhdr {
> > > |         ^~~~~~
> > > | In file included from
> ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:26:
> > > |
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/linux/if_ether.h:167:8:
> > > note: originally defined here
> > > | struct ethhdr {
> > > |         ^~~~~~
> > >
> > > glibc does not fail because it does include linux header
> > > | /* Get definitions from kernel header file.  */
> > > | #include <linux/if_ether.h>
> > > and does not define struct ethhdr
> > >
> > > linux/if_ether.h says:
> > > /* allow libcs like musl to deactivate this, glibc does not implement
> this. */
> > > #ifndef __UAPI_DEF_ETHHDR
> > > #define __UAPI_DEF_ETHHDR        1
> > > #endif
> > >
> > > #if __UAPI_DEF_ETHHDR
> > > struct ethhdr {
> > >     unsigned char    h_dest[ETH_ALEN];    /* destination eth addr    */
> > >     unsigned char    h_source[ETH_ALEN];    /* source ether addr    */
> > >     __be16        h_proto;        /* packet type ID field    */
> > > } __attribute__((packed));
> > > #endif
> > >
> > > musl does not include linux header but defines which is differen from
> > > what linux does:
> > > struct ethhdr {
> > >     uint8_t h_dest[ETH_ALEN];
> > >     uint8_t h_source[ETH_ALEN];
> > >     uint16_t h_proto;
> > > };
> > > and later
> > > #define __UAPI_DEF_ETHHDR       0
> > >
> > > So for networkmanager there is either some wrong sequence or it
> > > includes linux headers.
> >
> > musl headers providing own different definitions of kernel interfaces
> > is a problem in musl.
> >
> > After reading [1] I think that this is musl upstream having made the
> > decision of not even trying to work properly with the kernel headers.
> >
> > OE adding a not upstreamable patch that removes one of the two
> > definitions in musl builds might be the best available solution.
> >
> > > And I am still not confident that it is our job to teach umpteen
> > > projects written for linux how to write portable code (oe-core has 147
> > > musl related patches and meta-openembedded has 140)...
> > >...
> >
> > This is not about writing portable code, this is about problems with
> musl.
> >
> > Using the Linux userspace headers is obviously not portable to non-Linux,
> > but many packages like NetworkManager are anyways Linux-only no matter
> > what you do.
> >
> > > Andreas
> >
> > cu
> > Adrian
> >
> > [1] https://wiki.musl-libc.org/faq.html#Q:-Why-am-I-getting-
> >
> Have looked into some papers at musl page and the link above: The more
> I read from them the less I am interested in wasting my time on it.
> There is too often this 'the world is full of idiots - and it is just
> us doing the right thing' between the lines. Starts that they call
> musl 'correct' - while their own performance charts are - for my use
> case - unacceptable (ok outdated - maybe things changed). One could
> say: Go and give it a try but there is just a little problem: I think
> it'll take weeks to get images with contents I interested in.
>
> Looked into networkmanager: There are dozen places where linux headers
> are used - I don't see a clean solution we could offer upstream.
>
> What bugs me most: Silently a rule was introduced that patches failing
> for musl are not accepted - or did I miss something. A project
> considering itself as center of the world blocks resources here in
> times these are limited.

No there is no rule like that it’s who shows up with interest and reports
problems I understand your usecase might not involve musl and that’s how
everyone is they have interest in some parts of project but they cooperate
with the things which don’t interest them so when I ask it’s breaking musl
I am trying to nudge them to help fixing it since I do the same when
someone approaches my patches and reports issues that could be fixed in
that and sometimes I express my helplessness and sometimes I do help if I
have knleoledge and time so I expect others to do same

>
>
> Just to add that I spent past three weekends to wipe after patches
> being removed / 'bit-rottened' stuff was removed from a layer I
> maintain right before next release. Ahh maintainer means take care /
> answer user questions take / complaints when something does not work -
> but when it comes to decisions: Please keep you mouth shut.

You can be direct and cite the case and may be it can be discussed further
if you are talking about gstreamer 0.10 then I thought you agreed for
removal since that’s what your email said but if it’s a different case then
I encourage you to bring it forward and discuss

I usually report my problems and of possible I send a fix and if something
of my interest is affected I try to help this works well in most cases

>
>
> it is enough
>
> Andreas
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190325/6ab3a08b/attachment-0001.html>