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.
Thank You
Ron Oakes
On Fri, Sep 9, 2016 at 10:01 AM, Ronald Oakes <rona...@brc2.com> wrote:
> 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 CD to attempt real hardware even
> if at this point that is just the same PC I'm developing on).
>
> 1: Upon each boot - or more correctly when I attempt to load my module
> as part of an init.d script - I get a couple of messages from my
> driver:
> "altadriver: module license 'Proprietary' taints kernel."
> followed by:
> "Disabling lock debugging due to kernel taint"
>
> Is there any way to prevent the prosperity license from tainting the
> kernel? As the kernel module is indeed under a proprietary license
> (which isn't a problem - my product has a single customer so licensing
> is not an issue), I don't want to override the license, but I don't
> want it to impact kernel debugging should other issues develop.
>
> 2: I'm also getting a number of Unknown symbol messages such as:
> "altadriver: Unknown symbol ___stack_chk_fail (err 0)"
>
> Am I correct that these indicate that I'm missing a runtime library
> dependency? If so, any suggestions on how to locate what library has
> the missing functions? I do have these modules working on the native
> system, so I know that I have the native versions of these libraries
> and just need to identify and add them to my target system.
>
> 3: Related to the previous question, how important is the name of the
> library in /usr/lib at the time that the module (or any other program)
> starts?
>
> On the native installer, one of the precompiled libraries gets
> installed as symbolic link called /usr/lib/<filename>.so pointing to
> where the file is unpacked. I was unable to successfully get a
> symbolic link of this name created on my target yesterday (even though
> the same recipe created two other symbolic links in /usr/lib of the
> same format), leaving only the actual file (named
> /usr/lib/<filename>.so.<version>). So, I modified my init.d script to
> create the symbolic link before calling the program that, I believe,
> installs the module (the program is a vendor supplied pre-compiled
> binary that is used to create the device for the vendor hardware).
> However, if the module is installed before that it is possible that
> the symbolic link doesn’t exist but the library file is in /usr/lib
> under a different but related name.
>
> Thank You
> Ron Oakes
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
