Re: musl thoughts

["Andreas Müller" <schnitzeltony@gmail.com>]

On Mon, Mar 25, 2019 at 6:46 PM Adrian Bunk <bunk@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.

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.

it is enough

Andreas