On 2018-07-12 1:02 PM, Khem Raj wrote:
On 7/12/18 7:55 AM, Bruce Ashfield wrote:
On 2018-07-12 9:53 AM, Richard Purdie wrote:
On Thu, 2018-07-12 at 09:49 -0400, Bruce Ashfield wrote:
On 2018-07-10 5:41 PM, Richard Purdie wrote:
On Tue, 2018-07-10 at 12:38 -0400, Bruce Ashfield wrote:
On 07/10/2018 06:21 AM, Richard Purdie wrote:
On Mon, 2018-07-09 at 11:53 -0400, Bruce Ashfield wrote:
I'll try the other configs, but clearly I have something
different in
my x86-64 build.
I can't run the self tests directly, but am copying the files
onto my
qemu session and running things myself:
root@qemux86-64:/lib/modules/4.14.48-yocto-standard/build# make
ARCH=x86
scripts prepare
Makefile:950: "Cannot use CONFIG_STACK_VALIDATION=y, please
install
libelf-dev, libelf-devel or elfutils-libelf-devel"
CHK scripts/mod/devicetable-offsets.h
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h
SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h
SYSTBL arch/x86/include/generated/asm/syscalls_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
HOSTCC arch/x86/tools/relocs_32.o
HOSTCC arch/x86/tools/relocs_64.o
HOSTCC arch/x86/tools/relocs_common.o
HOSTLD arch/x86/tools/relocs
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
Makefile:950: "Cannot use CONFIG_STACK_VALIDATION=y, please
install
libelf-dev, libelf-devel or elfutils-libelf-devel"
root@qemux86-64:/tmp# make
make -C /usr/src/kernel M=/tmp modules
make[1]: Entering directory '/lib/modules/4.14.48-yocto-
standard/build'
Makefile:950: "Cannot use CONFIG_STACK_VALIDATION=y, please
install
libelf-dev, libelf-devel or elfutils-libelf-devel"
Building modules, stage 2.
MODPOST 1 modules
make[1]: Leaving directory '/lib/modules/4.14.48-yocto-
standard/build'
root@qemux86-64:/tmp# insmod hellomod.ko
[ 419.211616] hellomod: loading out-of-tree module taints
kernel.
[ 419.212586] Hello world!
This is on the core-image-kernel-dev image, which is the one that
I created to test all this.
What image is that using ? some sato sdk one ?
We really need to find you a way to run these. The problem is the
qemu
graphics piece? You can't have a dummy vncserver or something to
direct
them at?
The image is a core-image-sato-sdk...
I was able to trigger the objtool issue with this image, looking at
fixing it and the other arches now.
Since its image related, is it a missing package dependency? Just
curious why its happening with some images but not your test ones...
It is. I have extra toolchain elements being installed in
core-image-kernel-dev
that hold things together (i.e. the kernel's objtool doesn't need to
be built).
The obvious fix is to just add an RDEPENDS, but I'm being stubborn
and trying to make it build on target, since the build of objtool from
the kernel source is showing me some sort of include path issue that
I'd like to sort out:
CC /lib/modules/4.14.48-yocto-standard/build/tools/objtool/exec-cmd.o
exec-cmd.c: In function 'get_pwd_cwd':
exec-cmd.c:49:4: error: implicit declaration of function 'strlcpy'; did
you mean 'strncpy'? [-Werror=implicit-function-declaration]
strlcpy(cwd, pwd, PATH_MAX);
^~~~~~~
strncpy
exec-cmd.c:49:4: error: nested extern declaration of 'strlcpy'
[-Werror=nested-externs]
cc1: all warnings being treated as errors
Kernel has this function defined in tools/include/linux/string.h so
Well yes, a grep locates that :D
however it has it like this
#if defined(__GLIBC__) && !defined(__UCLIBC__)
extern size_t strlcpy(char *dest, const char *src, size_t size);
#endif
Which means it will not work for musl and we need to ensure that we
use -D_GNU_SOURCE for it to be included from standard musl headers
I've never built or supported musl, and since this is using the
in kernel Makefiles, etc, it isn't something I can patch or fix
outside of linux-yocto.
I'm just worried about the glibc cases, we can do follow up patches
later.
Bruce
Cheers,
Bruce
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
