Yocto complains about two recipes installing the same header file

user_14666607 0
Viewed 813

When building an image using bitbake, the build complains about how this particular header file (under /usr/include == kernel header file?) is being installed by both the recipes.

./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'

Observation

I first looked for scsi_ioctl.h inside the source directory...to no avail.

Then, I tried looking into the respective recipe files both of which require the .inc file so I opened that instead.

  • I see glibc-initial depends on linux-libc-headers, which merely means (according to my understanding) that bitbake builds linux-libc-headers first prior to glibc-initial.

  • linux-libc-headers removes the scsi.h. (Not sure if it's related to the current header it's complaining about)

  • I also see a long note in linux-libc-headers.inc that talks about how you do not have to add libc custom extensions to the kernel. In addition, it says if you need to use kernel drivers, get them from STAGING_KERNEL_DIR, which is set in bitbake.conf to "${TMPDIR}/work-shared/${MACHINE}/kernel-source", and I already see scsi_ioctl.h is located there.

// 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.

Question/Concern

  • if the recipes themselves aren't installing the header file, who else may be? I am missing out on the point but that's because I'm still new to yocto and trying to figure things out.
  • Shouldn't yocto be looking into the build/tmp/work/<machine-name> and not build/tmp/work/aarch64-poky-linux, where <machine-name> is whatever it's set to in build/conf/local.conf file, which isn't aarch64

Appreciate any help

bitbake yocto embedded-linux linux-kernel linux
1 Answers

Please specify what version of yocto (gatesgarth etc) you are using.

As glibc is a very common package, I assume something has gotten messed up with your yocto tmp directory rather than a problem with yocto itself. (In my dunfell build, scsi_ioctl.h appears only under the glibc recipe.) Current yocto builds a distinct sysroot for each package, but in earlier versions used a common sysroot and it was rather fragile.

You can try:

bitbake -c cleanall glibc
bitbake -c cleanall linux-libc-headers

then rebuild. If that doesn't work, you can try the nuclear option of renaming tmp to some other name and re-running your build. If you've been using the same tmp through more than one yocto version or more than one kernel recipe, I definitely recommend a fresh start.

Re: tmp/work/<machine> vs tmp/work/<arch>; yocto tries to reuse build products as widely as possible. If a package is machine-specific (e.g. the kernel and device tree) it gets built under tmp/work/<machine>. If it is architecture-specific (e.g. compiled C code) but not machine-specific, it gets built under tmp/work/<arch>. A few packages (e.g. ca-certificates) are platform-independent, and are built in a tmp/work/<all> directory.

We build for several different Cortex A8 machines; most packages end up in tmp/work/coretexta8hf-neon-linux-gnueabi but a handful of packages have machine-specific overrides and end up in the machine-specific directories.

user_1983740
Related