Yocto 抱怨兩個配方安裝了相同的 header 文件

Question

使用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.

問題/關注

• 如果食譜本身沒有安裝 header 文件，還有誰？ 我錯過了這一點，但那是因為我還是 yocto 的新手並試圖弄清楚事情。
• yocto 不應該查看build/tmp/work/<machine-name>而不是build/tmp/work/aarch64-poky-linux ，其中<machine-name>是它在build/conf/local.conf中設置的任何內容build/conf/local.conf文件，它不是aarch64

感謝任何幫助

Answer 1

請指定您使用的是什么版本的 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但少數軟件包具有特定於機器的覆蓋並最終位於特定於機器的目錄中。