On Wed, Aug 28, 2019 at 6:47 PM Kang Kai <[email protected]> wrote: > > On 2019/8/29 上午5:40, Adrian Bunk wrote: > > On Wed, Aug 28, 2019 at 01:32:52PM -0700, Khem Raj wrote: > >> On Wed, Aug 28, 2019 at 12:56 PM Adrian Bunk <[email protected]> wrote: > >>> On Wed, Aug 28, 2019 at 11:53:27AM -0700, Khem Raj wrote: > >>>> On Wed, Aug 28, 2019 at 11:06 AM Adrian Bunk <[email protected]> wrote: > >>>>> What about marking networkmanager as incompatible with musl instead of > >>>>> maintaining an ever-growing mess? > >>>>> > >>>> if the fix is specifically done for musl alone then I would agree, but > >>>> in many cases, the fixes > >>>> have been cleaning up assumptions in kernel UAPI headers on glibc > >>>> provided headers > >>>> which is a good thing, and it does take some time for kernel header > >>>> changes to flow upstream > >>>> but eventually, they do. e.g. see [1] > >>> This is not a cleanup, this is a workaround for a misfeature of musl. > >>> > >>> The kernel userspace headers are the userspace ABI of the kernel for > >>> usage by all C libraries provided in one place, they are not tied to > >>> any specific C library. > >>> > >>> musl upstream does not even try to use the kernel userspace headers. > >>> > >>> The kernel userspace headers used to be a mess, but after more than 10 > >>> years of cleanup there is no excuse for musl to insist on providing own > >>> definitions of what is already provided by the kernel headers. > >> I was citing an example, you might have good feedback maybe bring it up > >> upstream with musl or > > musl upstream says the patched kernel-headers package from sabotage > > linux should be used: > > https://wiki.musl-libc.org/faq.html#Q:-Why-am-I-getting- > > There has been a patch of networkmanger for the headers issue. And I > update it then this problem gone. > > > > > >> ... > >>> There is a benefit of a small C library when your flash space is > >>> single-digit megabytes, but maintaining plenty of not upstreamable > >>> OE-only patches for using networkmanager on musl without a sane > >>> usecase is a waste of effort. > >> I have said it before as well, I will say it again if we can improve an > >> upstream > >> packages portability that itself is a good thing, but we should not go > >> overboard > >> if its too much of work. > > Networkmanager doesn't aim at portability and is too much work. > > Yes, another following issue is that NetworkManger uses non-posix > portable functions mrand48_r() and struct drand48_data. musl doesn't > recognize them. > After adapt to posix functions jrand48(), it segment fault when startup. > (The point of segment fault is far from my patch). Still working on it. :( >
Can you look at https://code.foxkit.us/adelie/packages/tree/master/user/networkmanager especially https://code.foxkit.us/adelie/packages/blob/master/user/networkmanager/random.patch > Regards, > Kai > > > > > >> there are container distros using musl so we > >> have a wide > >> list of packages which work well with musl, and this list is always > >> increasing, so I > >> would refrain from pushing musl to a narrow usecase > > AFAIK OE is the only distribution trying to build software like systemd > > or networkmanager with musl, and container distros optimized for size > > are only supporting smaller alternatives. > > > > cu > > Adrian > > > > -- > Kai Kang > -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
