On 03/30/2016 09:58 AM, Hongxu Jia wrote:
Its possible software may mix from shared-work and from some local
kernel module build too, not sure if/how well the code copes with that
case.
Currently kernel module has no dbg package generated, but I will
try to open it, and please wait my report for this case.
Hi Richard,
It is hardly to generate dbg for kernel module, it explicitly ignore
them and strip them.
In meta/classes/package.bbclass:
...
377 # We ignore kernel modules, we don't generate debug info files.
378 if file.find("/lib/modules/") != -1 and file.endswith(".ko"):
379 return 1
...
943 if (d.getVar('INHIBIT_PACKAGE_STRIP', True) != '1'):
944 for root, dirs, files in cpath.walk(dvar):
945 for f in files:
946 file = os.path.join(root, f)
947 if file.endswith(".ko") and
file.find("/lib/modules/") != -1:
948 kernmods.append(file)
949 continue
...
(I tried, but lots of failures and make no sense)
I could not get a case that software gets sources from shared-work and
local kernel module build. But if local kernel module build does not in
work-shared or software's WORKDIR, this fix could not do the collection
from local kernel module.
This fix could collect sources from work-shared and recipes's WORKDIR
(such as gcc).
//Hongxu
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
