[OE-core] musl thoughts
Andreas Müller
schnitzeltony at gmail.com
Mon Mar 25 17:36:19 UTC 2019
On Mon, Mar 25, 2019 at 6:15 PM Andreas Müller <schnitzeltony at gmail.com> wrote:
>
> On Mon, Mar 25, 2019 at 5:26 PM Andreas Müller <schnitzeltony at gmail.com> wrote:
> >
> > On Mon, Mar 25, 2019 at 5:10 PM Adrian Bunk <bunk at stusta.de> wrote:
> > >
> > > On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote:
> > > > On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller <schnitzeltony at gmail.com> wrote:
> > > > >
> > > > > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk <bunk at stusta.de> wrote:
> > > > > >
> > > > > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote:
> > > > > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk <bunk at stusta.de> wrote:
> > > > > > > >
> > > > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> > > > > > > > >...
> > > > > > > > > There are certain design aspects of musl which are actually turning
> > > > > > > > > out to be good
> > > > > > > > > e.g. there is no __MUSL__ define, so non-portable code can not be
> > > > > > > > > hidden which is a good thing,
> > > > > > > > >...
> > > > > > > >
> > > > > > > > Please take a closer look at some of the musl changes to NM that made
> > > > > > > > upgrading NM so hard for Andreas.
> > > > > > > >
> > > > > > > > +#if defined(__GLIBC__)
> > > > > > > > #include <net/ethernet.h>
> > > > > > > > +#else /* musl libc */
> > > > > > > > +#define ETH_ALEN 6 /* Octets in one ethernet addr */
> > > > > > > > +#endif
> > > >...
> > > >
> > > > Hi,
> > >
> > > Hi Andrea,
> > >
> > > > I am jumping in a little late to take side with Khem :)
> > > >
> > > > What happens now is that more 'bad' sources (written to suit glibc and
> > > > thus not portable) are discovered by the wider base of developers and
> > > > autobuilders.
> > > >...
> > >
> > > but this does not apply to this example, which is a problem between
> > > musl itself and the kernel headers.
> > >
> > > Code can expect #include <foo.h> to work for any headers, and with any
> > > order of these headers. If it does not, the 'bad' sources are whatever
> > > sources provide the headers in question.
> > >
> > > musl does provide net/ethernet.h, but including it causes a compile
> > > error here.
> > Out of curiosity: you have some log?
> >
> 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.
>
> 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)...
>
> [1] http://errors.yoctoproject.org/Errors/Details/198239/
>
Something to add - haven't yet looked into networkmanger:
Do we have the chance to change the sequence of paths headers are searched for
1. musl
2. linux
That might fix some issues
Andreas
> Andreas
More information about the Openembedded-core
mailing list