Re: musl thoughts

[Adrian Bunk <bunk@stusta.de>]

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-

-- 

       "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