On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk <b...@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 <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. > > As you have experienced, it does create a huge technical debt to ship > workaround patches in several recipes instead of fixing the bug in musl. > > > The last example could be fixed easily at musl shipping a ethernet.h > > containing > > #define ETH_ALEN 6 > >... > > That's already shipped by musl. > > But there seems to be some incompatibility between musl and the > kernel headers used by musl. > > This has to be sorted out in musl and/or the kernel headers. > Although I did not want to I'll start a musl build to create a cleanup for NM (and maybe) other musl patches.
Andreas -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
