On Thu, 2015-07-30 at 16:23 +0200, David Herrmann wrote: > Hi > > On Thu, Jul 30, 2015 at 3:50 PM, Paul Gortmaker > <paul.gortmaker@xxxxxxxxxxxxx> wrote: > > On 2015-07-29 12:31 PM, David Herrmann wrote: > >> Hi > >> > >> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker > >> <paul.gortmaker@xxxxxxxxxxxxx> wrote: > >>> Hi David, > >>> > >>> Does it make sense to build this sample when cross compiling? > >>> > >>> The reason I ask is that it has been breaking the linux-next build of > >>> allmodconfig for a while now, with: > >>> > >>> HOSTCC samples/kdbus/kdbus-workers > >>> samples/kdbus/kdbus-workers.c: In function ‘prime_new’: > >>> samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function) > >>> p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC); > >>> ^ > >>> samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in > >>> scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed > >>> make[2]: *** [samples/kdbus/kdbus-workers] Error 1 > >> > >> mips does have this syscall, so I assume the problem is out-of-date > >> kernel headers. You can fix this by running: > >> > >> $ make headers_install > > > > No, let me try and clarify. Please note the emphasis on cross compiling > > and automated build coverage, i.e. there is no place for manual steps. > > User-space samples in ./samples/ are compiled with HOSTCC, which is > the compiler for the _local_ machine. Regardless of cross-compiling > the same local compiler is used. So I cannot understand why this is > even remotely related to cross compiling. Please elaborate. > Please note that this is HOSTCC running, so it does *NOT* require the > toolchain for your cross-compiled architecture. Right. Our cross toolchain wouldn't build it anyway, as it has no libc. > Also, please tell me why your system has "linux/memfd.h" available, > but __NR_memfd_create is undefined? Because it's building with the HOSTCC (x86_64), against the MIPS kernel headers. And the MIPS kernel headers are structured in such a way that on a non-mips build they don't define the syscall numbers. The reason we have the MIPS headers installed is because CONFIG_HEADERS_CHECK is turned on (because allmodconfig). So that just basically makes no sense to me. It's obviously possible that some samples build with that configuration, but building against another arch'es kernel headers just seems like it's asking for trouble. Even if we can build the samples, they will never run correctly. So I suggest we should just disable SAMPLES if we're cross compiling, full stop. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
