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

[Kang Kai]

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. :(

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