[OE-core] [PATCH v2] kernel-devsrc: restructure for out of tree (and on target) module builds

[Bruce Ashfield]

On 2018-07-12 1:22 PM, Khem Raj wrote:
> On 7/12/18 11:07 AM, Bruce Ashfield wrote:
>> 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 at 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 at 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 at 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.
>>
> you dont have to defer since you are already touching this area you
> might very well address this too.
> Once the -I path is figured out. All we need is ensure -D_GNU_SOURCE is
> added to CFLAGS in same place.

I'll see how nasty it looks, but yah, if I'm in modifying things
anyway, I'll make sure that is added.

Bruce

> 
>> Bruce
>>
>>>
>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Richard
>>>>>
>>>>
>>>
>>>
>>
> 
>