On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk <b...@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 > > Using __GLIBC__ in workarounds for bugs in musl is wrong, > and cannot be upstreamed since it would do the wrong thing > on other non-broken C libraries. > > > While the eyes may hurt > > to see them, it does serve a > > good reminder of whats needed for a given package. > >... > > Who is responsible for fixing the root causes of such bugs in musl, > so that the workaround patches can be dropped from packages like NM? > > cu > Adrian If I am not mistaken nobody is responsible. It is recipe wise: Sending out a patch that fails for musl is rejected usually.
The last example could be fixed easily at musl shipping a ethernet.h containing #define ETH_ALEN 6 or at NM #ifndef ETH_ALEN #define ETH_ALEN 6 #endif Andreas -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
