[oe] [meta-networking][RFC PATCH 0/1] Failed to compile networkmanager with musl

[Khem Raj]

On Wed, Aug 28, 2019 at 6:47 PM Kang Kai <Kai.Kang at windriver.com> 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 <bunk at stusta.de> 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 <bunk at stusta.de> 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
>