From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Korsgaard Date: Tue, 20 Sep 2016 15:04:12 +0200 Subject: [Buildroot] [PATCH 2/2] python-psutil: fix build against musl C library In-Reply-To: <20160920143837.5bed86bd@free-electrons.com> (Thomas Petazzoni's message of "Tue, 20 Sep 2016 14:38:37 +0200") References: <20160920074127.22328-1-peter@korsgaard.com> <20160920074127.22328-2-peter@korsgaard.com> <20160920121433.3912ca4a@free-electrons.com> <8760pq50es.fsf@dell.be.48ers.dk> <20160920133053.3cb8e9bc@free-electrons.com> <87shsu3i2z.fsf@dell.be.48ers.dk> <20160920143837.5bed86bd@free-electrons.com> Message-ID: <8737ku3epf.fsf@dell.be.48ers.dk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net >>>>> "Thomas" == Thomas Petazzoni writes: Hi, >> I don't see the point of that reasoning - The whole idea of the Linux >> uapi headers is to provide headers for the kernel API. > Correct. I've already discussed this with the musl developers, and they > say that the "kernel headers are not clean to be used in userspace". > Of course, everyone else but the musl people are using the uapi headers > in userspace, but apparently, there are some things in there that do > not please the musl people. > Maybe Rich can explain more precisely the issue. So far I've only been > able to get "kernel headers are not clean enough", but not concrete > example of the problem. Rich, can you explain please? >> I'm not particulary interested in musl support for >> python-psutil. Alternatively we can just mark it as >> !BR2_TOOLCHAIN_USES_MUSL. >> >> What do you suggest? > I don't care about python-psutil to be available with musl, so your > proposal is fine to me. Overall, I find the policy of musl developers > to be very annoying as: > 1/ It breaks many many many packages. > 2/ The only proposed solution is to duplicate code, which is not nice > at all, and is difficult to get accepted by upstream project, > living us with zillions of musl-related patches that we cannot > upstream. Agreed. I've send a patch to mark it (and its reverse dependencies) as unavailable on musl. -- Venlig hilsen, Peter Korsgaard