On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller <schnitzelt...@gmail.com> wrote: > > 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
Hi, 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. I myself did struggle in the years to maintain a few packages deeply bound to the kernel (mtd-utils, kexec tools) 'compatible' with klibc so I know the pain. As Khem said, this just needs time and efforts to clean up and upstream the patches. Cheers Andrea -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
