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
On Mon, Sep 12, 2016 at 01:41:24PM -0300, Daniel. wrote:
> If you don't make your driver GPL you can't access GPL symbols. This
> *may* be the reason behind the "Unknown symbols"
> Regards,
Well at least for __stack_chk_fail the kernel has:
#ifdef CONFIG_CC_STACKPROTECTOR
/*
* Called when
Ronald,
If you don't make your driver GPL you can't access GPL symbols. This
*may* be the reason behind the "Unknown symbols"
Regards,
2016-09-12 13:02 GMT-03:00 Lennart Sorensen :
> On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote:
>> Following up as
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
> .so by explicitly including a runtime dependency
> (RDEPENDS_${PN}) to the -dev
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
.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
I have some, I presume naive, questions about some messages I'm
getting as a result of running (or attempting to run) my
vendor-provided kernel module under qemu. (I've not tried on the real
hardware yet, I'd like it at least to boot somewhat cleaner on the
emulator before I commit to burning a