I was able to resovle my problem (with a bit of help from Google and
Stack Overflow) by including a stub version of __stack_check_fail() in
my recepie.
It appears that the shared object libarary was not needed after all,
and was just a red herring in my invesgagation.
Thank you for your assistance.
Ron Oakes
On Mon, Sep 12, 2016 at 10:02 AM, Lennart Sorensen
<lsore...@csclub.uwaterloo.ca> wrote:
> On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote:
>> Following up as I've done more investigation and debugging this afternoon:
>>
>> I've been able to resolve my problem with the missing symbolic link to
>> <filename>.so by explicitly including a runtime dependency
>> (RDEPENDS_${PN}) to the -dev module, so my link is now present on the
>> filesystem image at boot. I've also found reasonably strong evidence
>> that that library contains the function __stack_chk_fail; but the
>> evidence could equally indicate that that library calls it as I found
>> the string using the strings function.
>>
>> Either way, it looks like I have a critical kernel module, and a less
>> critical kernel module, that are relying on a shared library that
>> either are missing on my image or are not available properly in kernel
>> space. Any suggestions on how I can resolve this would be greatly
>> appreciated.
>
> Kernel modules only use kernel code. They never use user space libraries.
> It simply doesn't work that way.
>
> --
> Len Sorensen
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
