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