[英]Yocto complains about two recipes installing the same header file
使用bitbake
构建图像时,构建抱怨这个特定的 header 文件(在/usr/include
== kernel header 文件下是如何安装的?)
./tmp/work/aarch64-poky-linux/glibc/2.27-r0/temp/log.do_prepare_recipe_sysroot.21803:807:DEBUG: Removing manifest: /repo/build/tmp/work/aarch64-poky-linux/glibc/2.27-r0/recipe-sysroot/usr/include/scsi/scsi_ioctl.h
ERROR: glibc-2.27-r0 do_prepare_recipe_sysroot: The file /usr/include/scsi/scsi_ioctl.h is installed by both linux-libc-headers and glibc-initial, aborting
ERROR: glibc-2.27-r0 do_prepare_recipe_sysroot: Function failed: extend_recipe_sysroot
/tmp/work/aarch64-poky-linux/glibc/2.27-r0/temp/log.do_prepare_recipe_sysroot.16343:976:Exception: FileExistsError: [Errno 17] File exists: '/repo/build/tmp/sysroots-components/aarch64/linux-libc-headers/usr/include/scsi/scsi_ioctl.h' -> 'repo/build/tmp/work/aarch64-poky-linux/glibc/2.27-r0/recipe-sysroot/usr/include/scsi/scsi_ioctl.h'
观察
我首先在source
目录中查找scsi_ioctl.h
......无济于事。
然后,我尝试查看各自的配方文件,这两个文件都需要.inc
文件,所以我打开了它。
我看到glibc-initial
取决于linux-libc-headers
,这仅意味着(根据我的理解) bitbake
在glibc-initial
之前首先构建linux-libc-headers
。
linux-libc-headers
删除scsi.h
。 (不确定它是否与它抱怨的当前 header 有关)
我还在linux-libc-headers.inc
中看到了一个很长的注释,它谈到了如何不必将libc
自定义扩展添加到 kernel。 此外,它说如果您需要使用 kernel 驱动程序,请从STAGING_KERNEL_DIR
获取它们,它在bitbake.conf
中设置为"${TMPDIR}/work-shared/${MACHINE}/kernel-source"
,我已经看到了scsi_ioctl.h
位于那里。
// glibc-initial.inc
DEPENDS = "linux-libc-headers virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
PROVIDES = "virtual/${TARGET_PREFIX}libc-initial"
....
do_install () {
oe_runmake cross-compiling=yes install_root=${D} \
includedir='${includedir}' prefix='${prefix}' \
install-bootstrap-headers=yes install-headers
oe_runmake csu/subdir_lib
mkdir -p ${D}${libdir}/
install -m 644 csu/crt[1in].o ${D}${libdir}
// linux-libc-headers.inc
do_install() {
oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix}
# Kernel should not be exporting this header
rm -f ${D}${exec_prefix}/include/scsi/scsi.h
# The ..install.cmd conflicts between various configure runs
find ${D}${includedir} -name ..install.cmd | xargs rm -f
}
#########################################################################
#### PLEASE READ
#########################################################################
#
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
#
# Why? These headers are used to build the libc. If you customise the
# headers you are customising the libc and the libc becomes machine
# specific. Most people do not add custom libc extensions to the kernel
# and have a machine specific libc.
#
# But you have some kernel headers you need for some driver? That is fine
# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
# This will make the package using them machine specific but this is much
# better than having a machine specific C library. This does mean your
# recipe needs a
# do_configure[depends] += "virtual/kernel:do_shared_workdir"
# but again, that is fine and makes total sense.
#
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
问题/关注
build/tmp/work/<machine-name>
而不是build/tmp/work/aarch64-poky-linux
,其中<machine-name>
是它在build/conf/local.conf
中设置的任何内容build/conf/local.conf
文件,它不是aarch64
感谢任何帮助
请指定您使用的是什么版本的 yocto(gatesgarth 等)。
由于 glibc 是一个非常常见的 package,我认为您的 yocto tmp
目录已经搞砸了,而不是 yocto 本身的问题。 (在我的 dunfell 构建中, scsi_ioctl.h
仅出现在 glibc 配方下。)当前的 yocto 为每个 package 构建了一个不同的 sysroot,但在早期版本中使用了一个通用的 sysroot,它相当脆弱。
你可以试试:
bitbake -c cleanall glibc
bitbake -c cleanall linux-libc-headers
然后重建。 如果这不起作用,您可以尝试将tmp
重命名为其他名称并重新运行您的构建的核选项。 如果您通过多个 yocto 版本或多个 kernel 配方使用相同的tmp
,我绝对建议您重新开始。
回复: tmp/work/<machine>
vs tmp/work/<arch>
; yocto 尝试尽可能广泛地重用构建产品。 如果 package 是特定于机器的(例如 kernel 和设备树),它将在tmp/work/<machine>
下构建。 如果它是特定于架构的(例如编译的 C 代码)但不是特定于机器的,它会在tmp/work/<arch>
下构建。 一些软件包(例如ca-certificates
)与平台无关,并且构建在tmp/work/<all>
目录中。
我们为几种不同的 Cortex A8 机器构建; 大多数软件包最终位于tmp/work/coretexta8hf-neon-linux-gnueabi
但少数软件包具有特定于机器的覆盖并最终位于特定于机器的目录中。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.