Message ID | 20160920074127.22328-2-peter@korsgaard.com |
---|---|
State | Rejected |
Headers | show |
Hello, On Tue, 20 Sep 2016 09:41:27 +0200, Peter Korsgaard wrote: > We NEED both sys/sysinfo.h and the kernel headers (E.G. for ethtool), so > hack around it by ensuring the content of linux/sysinfo.h doesn't get > expanded when building against musl. > > We cannot do it unconditionally as glibc/uClibc rely on the linux/sysinfo.h > definition. Musl provides no detection define, so instead detect that we > are NOT on glibc/uClibc. This is not really the solution recommended by the musl developers. Instead, the musl developers would suggest to *not* include <linux/sysinfo.h> at all, and instead duplicate the relevant definitions in the userspace program. Best regards, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Hello, > On Tue, 20 Sep 2016 09:41:27 +0200, Peter Korsgaard wrote: >> We NEED both sys/sysinfo.h and the kernel headers (E.G. for ethtool), so >> hack around it by ensuring the content of linux/sysinfo.h doesn't get >> expanded when building against musl. >> >> We cannot do it unconditionally as glibc/uClibc rely on the linux/sysinfo.h >> definition. Musl provides no detection define, so instead detect that we >> are NOT on glibc/uClibc. > This is not really the solution recommended by the musl developers. > Instead, the musl developers would suggest to *not* include > <linux/sysinfo.h> at all, and instead duplicate the relevant > definitions in the userspace program. Yes, I know it is a hack (as mentioned in the description). The problem is that the code DOESN'T include linux/sysinfo.h, but it gets indirectly included from linux/ethtool.h -> linux/kernel.h -> linux/sysinfo.h. Do you have any suggestion how to fix this in a cleaner way?
Hello, On Tue, 20 Sep 2016 12:30:03 +0200, Peter Korsgaard wrote: > > This is not really the solution recommended by the musl developers. > > Instead, the musl developers would suggest to *not* include > > <linux/sysinfo.h> at all, and instead duplicate the relevant > > definitions in the userspace program. > > Yes, I know it is a hack (as mentioned in the description). The problem > is that the code DOESN'T include linux/sysinfo.h, but it gets indirectly > included from linux/ethtool.h -> linux/kernel.h -> linux/sysinfo.h. > > Do you have any suggestion how to fix this in a cleaner way? The answer of the musl developers would be: don't include <linux/ethtool.h> in the first place. Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Hello, > On Tue, 20 Sep 2016 12:30:03 +0200, Peter Korsgaard wrote: >> > This is not really the solution recommended by the musl developers. >> > Instead, the musl developers would suggest to *not* include >> > <linux/sysinfo.h> at all, and instead duplicate the relevant >> > definitions in the userspace program. >> >> Yes, I know it is a hack (as mentioned in the description). The problem >> is that the code DOESN'T include linux/sysinfo.h, but it gets indirectly >> included from linux/ethtool.h -> linux/kernel.h -> linux/sysinfo.h. >> >> Do you have any suggestion how to fix this in a cleaner way? > The answer of the musl developers would be: don't include > <linux/ethtool.h> in the first place. 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. 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?
Hello, Adding Rich from musl in Cc. On Tue, 20 Sep 2016 13:51:16 +0200, Peter Korsgaard wrote: > > The answer of the musl developers would be: don't include > > <linux/ethtool.h> in the first place. > > 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. > 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. Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 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.
diff --git a/package/python-psutil/0001-fix-build-against-musl-C-library.patch b/package/python-psutil/0001-fix-build-against-musl-C-library.patch new file mode 100644 index 0000000..0ef994d --- /dev/null +++ b/package/python-psutil/0001-fix-build-against-musl-C-library.patch @@ -0,0 +1,63 @@ +From d08ba65306c7f9ac9c0590cfe313d3ce0f8873be Mon Sep 17 00:00:00 2001 +From: Peter Korsgaard <peter@korsgaard.com> +Date: Mon, 19 Sep 2016 23:41:54 +0200 +Subject: [PATCH] fix build against musl C library + +The sysinfo structure definition in linux/sysinfo.h (which gets indirectly +included from linux/kernel.h) conflicts with the definition in sys/sysinfo.h +when building against the musl C library, leading to build failures: + +http://autobuild.buildroot.net/results/365/365c2f0b32ae3cb1d6d4d8f0145500dfadd05c59/build-end.log + +arm-linux-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes \ + -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -fPIC -DPSUTIL_VERSION=430 \ + -c psutil/_psutil_linux.c -o build/temp.linux-x86_64-3.5/psutil/_psutil_linux.o +In file included from /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/kernel.h:4:0, + from /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/ethtool.h:16, + from psutil/_psutil_linux.c:35: +/home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/sysinfo.h:7:8: error: redefinition of 'struct sysinfo' + struct sysinfo { + ^ +In file included from psutil/_psutil_linux.c:21:0: +/home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/sys/sysinfo.h:10:8: note: originally defined here + +We NEED both sys/sysinfo.h and the kernel headers (E.G. for ethtool), so +hack around it by ensuring the content of linux/sysinfo.h doesn't get +expanded when building against musl. + +We cannot do it unconditionally as glibc/uClibc rely on the linux/sysinfo.h +definition. Musl provides no detection define, so instead detect that we +are NOT on glibc/uClibc. + +Signed-off-by: Peter Korsgaard <peter@korsgaard.com> +--- + psutil/_psutil_linux.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +diff --git a/psutil/_psutil_linux.c b/psutil/_psutil_linux.c +index 19fd14b..fa7617a 100644 +--- a/psutil/_psutil_linux.c ++++ b/psutil/_psutil_linux.c +@@ -16,6 +16,19 @@ + #include <features.h> + #include <utmp.h> + #include <sched.h> ++ ++#ifndef __GLIBC__ ++/* ++ * linux/sysinfo.h (which gets indirectly included by other kernel headers) ++ * conflicts with sys/sysinfo.h on musl, so make sure it doesn't get expanded. ++ * We cannot do this unconditionally as E.G. glibc/uClibc rely on the ++ * linux/sysinfo.h definition. ++ * Musl provides no detection define, so instead detect that we are ++ * NOT on glibc/uClibc. ++ */ ++#define _LINUX_SYSINFO_H ++#endif ++ + #include <linux/version.h> + #include <sys/syscall.h> + #include <sys/sysinfo.h> +-- +2.9.3 +
Fixes: http://autobuild.buildroot.net/results/365/365c2f0b32ae3cb1d6d4d8f0145500dfadd05c59/ http://autobuild.buildroot.org/results/140/140d0ec9d94f75453c4c82e18803c8d7bffcf6be/ And many more. The sysinfo structure definition in linux/sysinfo.h (which gets indirectly included from linux/kernel.h) conflicts with the definition in sys/sysinfo.h when building against the musl C library, leading to build failures: arm-linux-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes \ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -fPIC -DPSUTIL_VERSION=430 \ -c psutil/_psutil_linux.c -o build/temp.linux-x86_64-3.5/psutil/_psutil_linux.o In file included from /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/kernel.h:4:0, from /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/ethtool.h:16, from psutil/_psutil_linux.c:35: /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/sysinfo.h:7:8: error: redefinition of 'struct sysinfo' struct sysinfo { ^ In file included from psutil/_psutil_linux.c:21:0: /home/buildroot/build/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/sys/sysinfo.h:10:8: note: originally defined here We NEED both sys/sysinfo.h and the kernel headers (E.G. for ethtool), so hack around it by ensuring the content of linux/sysinfo.h doesn't get expanded when building against musl. We cannot do it unconditionally as glibc/uClibc rely on the linux/sysinfo.h definition. Musl provides no detection define, so instead detect that we are NOT on glibc/uClibc. Signed-off-by: Peter Korsgaard <peter@korsgaard.com> --- .../0001-fix-build-against-musl-C-library.patch | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 package/python-psutil/0001-fix-build-against-musl-C-library.patch