Re: [yocto] Clang LLVM do_package strip error
On Mon, Oct 23, 2023 at 5:43 PM Khem Raj wrote:
>
> On Mon, Oct 23, 2023 at 9:29 AM Martin Townsend
> wrote:
> >
> > Hi,
> >
> > I've updated the project I'm working on to kirkstone and using GCC it
> > is working. We want to move to Clang but I've seen a couple of
> > recipes fail in do_package with a similar error. Here is the output
> > for runc-opencontainers, the package tini has something similar
> >
> >
> > ERROR: runc-opencontainers-1.1.4+gitAUTOINC+974efd2dfc-r0 do_package:
> > Fatal errors occurred in subprocesses:
> > Command '['aarch64-poky-linux-llvm-objcopy', '--only-keep-debug',
> > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/runc',
> > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/.debug/runc']'
> > returned non-zero exit status 1.
> > Subprocess output:aarch64-poky-linux-llvm-objcopy: error: Link field
> > value 47 in section .rela.plt is not a symbol table
> >
>
> Its using clang and also binutils from llvm here and there has been
> many fixes we had done to llvm
> tools and things are better with clang 17, but since you are on
> kirkstone, you might be using older clang
> and llvm. So you can try if master branch solves the problem and maybe
> next LTS you are set other
> option which might be immediately useful would be to fall back to
> using objcopy from binutils which you
> can do via something like below in site.conf
>
> OBJCOPY:pn-runc-opencontainers:toolchain-clang = "${HOST_PREFIX}objcopy"
>
Moving to master and modifying a few recipes has fixed these issues
but now docker and containerd-opencontainers are not compiling, for
containerd, grepping for error I can see
vendor/k8s.io/apimachinery/pkg/util/sets/byte.go:34:16: syntax error:
unexpected [, expecting (
vendor/k8s.io/apimachinery/pkg/util/sets/int.go:34:15: syntax error:
unexpected [, expecting (
vendor/k8s.io/apimachinery/pkg/util/sets/int32.go:34:17: syntax error:
unexpected [, expecting (
vendor/k8s.io/apimachinery/pkg/util/sets/int64.go:34:17: syntax error:
unexpected [, expecting (
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:24:10: syntax
error: unexpected |, expecting semicolon or newline or }
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:31:9: syntax
error: unexpected |, expecting semicolon or newline or }
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:38:2: syntax
error: unexpected ~, expecting method or interface name
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:45:2: syntax
error: unexpected ~, expecting method or interface name
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:52:2: syntax
error: unexpected ~, expecting method or interface name
vendor/k8s.io/apimachinery/pkg/util/sets/set.go:24:12: syntax error:
unexpected comparable, expecting ]
vendor/k8s.io/apimachinery/pkg/util/sets/set.go:24:12: too many errors
and
make: *** [Makefile:264: bin/containerd-shim] Error 2
make: *** [Makefile:268: bin/containerd-shim-runc-v1] Error 2
make: *** [Makefile:272: bin/containerd-shim-runc-v2] Error 2
make: *** [Makefile:255: bin/ctr] Error 2
make: *** [Makefile:255: bin/containerd-stress] Error 2
make: *** [Makefile:255: bin/containerd] Error 2
It looks like it's compiling go, do I need to do anything special for
clang to compile go? I tried updating the recipe to the latest from
master and still the same error.
The lines from the makefile are
define BUILD_BINARY
@echo "$(WHALE) $@"
$(GO) build ${DEBUG_GO_GCFLAGS} ${GO_GCFLAGS} ${GO_BUILD_FLAGS} -o $@
${GO_LDFLAGS} ${GO_TAGS} ./$<
endef
# Build a binary from a cmd.
bin/%: cmd/% FORCE
$(call BUILD_BINARY)
> > ERROR: Logfile of failure stored in:
> > /ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/temp/log.do_package.2936320
> > ERROR: Task
> > (/ws/extra/octopus/octave-kirkstone/build-cad-devel/../sources/meta-virtualization/recipes-containers/runc/runc-opencontainers_git.bb:do_package)
> > failed with exit code '1'
> > Pseudo log:
> > inode mismatch:
> > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/image/usr/bin/docker-runc'
> > ino 84410787 in db, 84431171 in request.
> > Setup complete, sending SIGUSR1 to pid 2936321.
> >
> > I'm sure these used to compile with Clang in dunfell so could this be
> > a toolchain problem?
> >
> > I'm using the kirkstone branch of meta-clang and have the following in
> > my distro conf
> > PREFERRED_PROVIDER_l
[yocto] Clang LLVM do_package strip error
Hi, I've updated the project I'm working on to kirkstone and using GCC it is working. We want to move to Clang but I've seen a couple of recipes fail in do_package with a similar error. Here is the output for runc-opencontainers, the package tini has something similar ERROR: runc-opencontainers-1.1.4+gitAUTOINC+974efd2dfc-r0 do_package: Fatal errors occurred in subprocesses: Command '['aarch64-poky-linux-llvm-objcopy', '--only-keep-debug', '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/runc', '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/.debug/runc']' returned non-zero exit status 1. Subprocess output:aarch64-poky-linux-llvm-objcopy: error: Link field value 47 in section .rela.plt is not a symbol table ERROR: Logfile of failure stored in: /ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/temp/log.do_package.2936320 ERROR: Task (/ws/extra/octopus/octave-kirkstone/build-cad-devel/../sources/meta-virtualization/recipes-containers/runc/runc-opencontainers_git.bb:do_package) failed with exit code '1' Pseudo log: inode mismatch: '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/image/usr/bin/docker-runc' ino 84410787 in db, 84431171 in request. Setup complete, sending SIGUSR1 to pid 2936321. I'm sure these used to compile with Clang in dunfell so could this be a toolchain problem? I'm using the kirkstone branch of meta-clang and have the following in my distro conf PREFERRED_PROVIDER_llvm = "clang" PREFERRED_PROVIDER_llvm-native = "clang-native" PREFERRED_PROVIDER_nativesdk-llvm = "nativesdk-clang" PROVIDES:pn-clang = "llvm" PROVIDES:pn-clang-native = "llvm-native" PROVIDES:pn-nativesdk-clang = "nativesdk-llvm" and this in local.conf TOOLCHAIN ?= "clang" RUNTIME ?= "llvm" I notice there is a kirkstone-clang12 branch in meta-clang, should I be using this? If not, any help in debugging this would be appreciated. Cheers, Martin. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61459): https://lists.yoctoproject.org/g/yocto/message/61459 Mute This Topic: https://lists.yoctoproject.org/mt/102139152/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] libgcc dependency
Hi,
I am trying to remove all GPLv3 packages from my image. The clang
toolchain is used where possible and currently there are no
dependencies on libstdc++ and as far as I can see none on libgcc but
this library is installed in the rootfs. I've created a script to
parse all elf binaries to see which one dynamically links against
libgcc but none do. I think it's being installed due to libgcc being
in the BASEDEPENDS but I can't see what is adding libgcc to this
variable. I'm using the dunfell version of yocto and base.bbclass has
def base_dep_prepend(d):
if d.getVar('INHIBIT_DEFAULT_DEPS', False):
return ""
return "${BASE_DEFAULT_DEPS}"
BASE_DEFAULT_DEPS = "virtual/${TARGET_PREFIX}gcc
virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
BASEDEPENDS = ""
BASEDEPENDS_class-target = "${@base_dep_prepend(d)}"
BASEDEPENDS_class-nativesdk = "${@base_dep_prepend(d)}"
but when I check the BASEDEPENDS for various recipes I get
BASEDEPENDS=" clang-cross-aarch64 virtual/libc libgcc
virtual/aarch64-poky-linux-compilerlibs gettext-native"
BASEDEPENDS_class-nativesdk=" clang-cross-aarch64 virtual/libc libgcc
virtual/aarch64-poky-linux-compilerlibs "
BASEDEPENDS_class-target=" clang-cross-aarch64 virtual/libc libgcc
virtual/aarch64-poky-linux-compilerlibs "
Is it possible to remove libgcc from the BASEDEPENDS somehow?
Although we are using Dunfell I'm happy to move to another release if
it's easier to achieve this.
Best Regards,
Martin.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60587): https://lists.yoctoproject.org/g/yocto/message/60587
Mute This Topic: https://lists.yoctoproject.org/mt/100194492/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Kernel Initramfs Problems
On Wed, Jan 27, 2021 at 8:01 PM Martin Townsend wrote: > > On Wed, Jan 27, 2021 at 6:21 PM Martin Townsend > wrote: > > > > Hi, > > > > I'm trying to get an initramfs working so I can load firmware early > > enough in the boot. So I've created an initramfs with the firmware > > files and a script to switch to the main root. I've set the following > > > > # Use the FIT image format > > KERNEL_IMAGETYPES += "fitImage" > > KERNEL_CLASSES += "kernel-fitimage" > > KERNEL_IMAGETYPE = "fitImage" > > KERNEL_IMAGETYPE_aarch64 = "fitImage" > > > > # Add the initramfs for loading the firmware files > > INITRAMFS_IMAGE_BUNDLE = "1" > > INITRAMFS_IMAGE = "octave-cad-image-initramfs" > > INITRAMFS_FSTYPES = "cpio.gz" > > > > in a configuration file. According to the docs for INITRAMFS_IMAGE_BUNDLE: > > "The unpacked initramfs image is then passed to the kernel's Makefile > > using the CONFIG_INITRAMFS_SOURCE variable, allowing the initramfs > > image to be built into the kernel normally. " > > > > Perfect, this is exactly what I want. Now I'm expecting the kernel > > image to contain the initramfs using CONFIG_INITRAMFS_SOURCE and not > > include the initramfs in the FIT image as an image configuration that > > U-Boot extracts and passes to the kernel. > > > > But I'm not seeing this. I get two FIT images deployed, one with an > > initramfs included as a configuration and a FIT image without. This > > doesn't seem right as the initramfs should already be in the kernel so > > including it in the FIT image means it would be there twice. Ignoring > > this the FIT image without an initramfs in the filename should still > > have the initramfs in the kernel via CONFIG_INITRAMFS_SOURCE but it's > > not there. When booting this image I don't see the firmware loading > > > > [0.629648][ T12] imx-sdma 302b.dma-controller: Direct > > firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 > > [0.638320][ T12] imx-sdma 302b.dma-controller: Falling back > > to sysfs fallback for: imx/sdma/sdma-imx7d.bin > > > > Now if I boot the FIT image with the initramfs in the filename I get > > > > [0.713335][ T12] imx-sdma 302b.dma-controller: loaded firmware 4.5 > > > > early in the boot so I know the initramfs works. > > > > So you could say use the FIT image with the initramfs in its filename > > but this isn't the FIT image that gets installed by > > packagegroup-core-boot and I can't find out how to use the other FIT > > image. I would prefer to bundle the initramfs into the kernel and not > > rely on the FIT image mechanism. > > > > I've tried building the kernel with all the INITRAMFS_* variables > > commented out and the file sizes are nearly the same, not quite but > > nearly. The initramfs is around 4MiB in size due to firmware files, > > busybox and the libraries that this requires to perform the > > switch_root. This also suggests that CONFIG_INITRAMFS_SOURCE isn't > > working. > > > > I've built the kernel with verbose on and see > > + > > use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build/usr/octave-cad-image-initramfs-octave-imx8mnevk.cpio > > > > > > and also > > + oe_runmake [snip] > > CONFIG_INITRAMFS_SOURCE=/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build/usr/octave-cad-image-initramfs-octave-imx8mnevk.cpio > > > > So it looks like this doesn't work for some reason. I am using NXP's > > vendor specific kernel but I don't think they've touched the kernel's > > build system. The kernel version is 5.4. The log does contain what > > looks like the Makefile actually performing the steps required > > > > GEN Makefile > > > > scripts/kconfig/conf --syncconfig Kconfig > > > > GEN Makefile > > > > CALL > > /ws/rufilla/octopus/octave-dunfell/build-release/tmp/work-shared/octave-imx8mnevk/kernel-source/scripts/checksyscalls.sh > > > > CALL > > /ws/rufilla/octopus/octave-dunfell/build-release/tmp/work-shared/octave-imx8mnevk/kernel-source/scripts/atomic/check-atomics.sh > > > > CHK include/generated/compile.h > > > > GEN usr/initramfs_data.cpio > > > > AS usr/initramfs_data.o > > > > AR
Re: [yocto] Kernel Initramfs Problems
On Wed, Jan 27, 2021 at 6:21 PM Martin Townsend wrote:
>
> Hi,
>
> I'm trying to get an initramfs working so I can load firmware early
> enough in the boot. So I've created an initramfs with the firmware
> files and a script to switch to the main root. I've set the following
>
> # Use the FIT image format
> KERNEL_IMAGETYPES += "fitImage"
> KERNEL_CLASSES += "kernel-fitimage"
> KERNEL_IMAGETYPE = "fitImage"
> KERNEL_IMAGETYPE_aarch64 = "fitImage"
>
> # Add the initramfs for loading the firmware files
> INITRAMFS_IMAGE_BUNDLE = "1"
> INITRAMFS_IMAGE = "octave-cad-image-initramfs"
> INITRAMFS_FSTYPES = "cpio.gz"
>
> in a configuration file. According to the docs for INITRAMFS_IMAGE_BUNDLE:
> "The unpacked initramfs image is then passed to the kernel's Makefile
> using the CONFIG_INITRAMFS_SOURCE variable, allowing the initramfs
> image to be built into the kernel normally. "
>
> Perfect, this is exactly what I want. Now I'm expecting the kernel
> image to contain the initramfs using CONFIG_INITRAMFS_SOURCE and not
> include the initramfs in the FIT image as an image configuration that
> U-Boot extracts and passes to the kernel.
>
> But I'm not seeing this. I get two FIT images deployed, one with an
> initramfs included as a configuration and a FIT image without. This
> doesn't seem right as the initramfs should already be in the kernel so
> including it in the FIT image means it would be there twice. Ignoring
> this the FIT image without an initramfs in the filename should still
> have the initramfs in the kernel via CONFIG_INITRAMFS_SOURCE but it's
> not there. When booting this image I don't see the firmware loading
>
> [0.629648][ T12] imx-sdma 302b.dma-controller: Direct
> firmware load for imx/sdma/sdma-imx7d.bin failed with error -2
> [0.638320][ T12] imx-sdma 302b.dma-controller: Falling back
> to sysfs fallback for: imx/sdma/sdma-imx7d.bin
>
> Now if I boot the FIT image with the initramfs in the filename I get
>
> [0.713335][ T12] imx-sdma 302b.dma-controller: loaded firmware 4.5
>
> early in the boot so I know the initramfs works.
>
> So you could say use the FIT image with the initramfs in its filename
> but this isn't the FIT image that gets installed by
> packagegroup-core-boot and I can't find out how to use the other FIT
> image. I would prefer to bundle the initramfs into the kernel and not
> rely on the FIT image mechanism.
>
> I've tried building the kernel with all the INITRAMFS_* variables
> commented out and the file sizes are nearly the same, not quite but
> nearly. The initramfs is around 4MiB in size due to firmware files,
> busybox and the libraries that this requires to perform the
> switch_root. This also suggests that CONFIG_INITRAMFS_SOURCE isn't
> working.
>
> I've built the kernel with verbose on and see
> +
> use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build/usr/octave-cad-image-initramfs-octave-imx8mnevk.cpio
>
>
> and also
> + oe_runmake [snip]
> CONFIG_INITRAMFS_SOURCE=/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build/usr/octave-cad-image-initramfs-octave-imx8mnevk.cpio
>
> So it looks like this doesn't work for some reason. I am using NXP's
> vendor specific kernel but I don't think they've touched the kernel's
> build system. The kernel version is 5.4. The log does contain what
> looks like the Makefile actually performing the steps required
>
> GEN Makefile
>
> scripts/kconfig/conf --syncconfig Kconfig
>
> GEN Makefile
>
> CALL
> /ws/rufilla/octopus/octave-dunfell/build-release/tmp/work-shared/octave-imx8mnevk/kernel-source/scripts/checksyscalls.sh
>
> CALL
> /ws/rufilla/octopus/octave-dunfell/build-release/tmp/work-shared/octave-imx8mnevk/kernel-source/scripts/atomic/check-atomics.sh
>
> CHK include/generated/compile.h
>
> GEN usr/initramfs_data.cpio
>
> AS usr/initramfs_data.o
>
> AR usr/built-in.a
>
> GEN .version
>
> CHK include/generated/compile.h
>
> LD vmlinux.o
>
> MODPOST vmlinux.o
>
> MODINFO modules.builtin.modinfo
>
> LD .tmp_vmlinux1
>
> KSYM.tmp_kallsyms1.o
>
> LD .tmp_vmlinux2
>
> KSYM.tmp_kallsyms2.o
>
> LD vmlinux
>
> SORTEX vmlinux
>
> SYSMAP System.map
>
> OBJCOPY arch/arm64/boot/Image
>
> ${B}/usr seems ok
>
> drwxr-xr-x 2 martin martin4
[yocto] Kernel Initramfs Problems
Hi,
I'm trying to get an initramfs working so I can load firmware early
enough in the boot. So I've created an initramfs with the firmware
files and a script to switch to the main root. I've set the following
# Use the FIT image format
KERNEL_IMAGETYPES += "fitImage"
KERNEL_CLASSES += "kernel-fitimage"
KERNEL_IMAGETYPE = "fitImage"
KERNEL_IMAGETYPE_aarch64 = "fitImage"
# Add the initramfs for loading the firmware files
INITRAMFS_IMAGE_BUNDLE = "1"
INITRAMFS_IMAGE = "octave-cad-image-initramfs"
INITRAMFS_FSTYPES = "cpio.gz"
in a configuration file. According to the docs for INITRAMFS_IMAGE_BUNDLE:
"The unpacked initramfs image is then passed to the kernel's Makefile
using the CONFIG_INITRAMFS_SOURCE variable, allowing the initramfs
image to be built into the kernel normally. "
Perfect, this is exactly what I want. Now I'm expecting the kernel
image to contain the initramfs using CONFIG_INITRAMFS_SOURCE and not
include the initramfs in the FIT image as an image configuration that
U-Boot extracts and passes to the kernel.
But I'm not seeing this. I get two FIT images deployed, one with an
initramfs included as a configuration and a FIT image without. This
doesn't seem right as the initramfs should already be in the kernel so
including it in the FIT image means it would be there twice. Ignoring
this the FIT image without an initramfs in the filename should still
have the initramfs in the kernel via CONFIG_INITRAMFS_SOURCE but it's
not there. When booting this image I don't see the firmware loading
[0.629648][ T12] imx-sdma 302b.dma-controller: Direct
firmware load for imx/sdma/sdma-imx7d.bin failed with error -2
[0.638320][ T12] imx-sdma 302b.dma-controller: Falling back
to sysfs fallback for: imx/sdma/sdma-imx7d.bin
Now if I boot the FIT image with the initramfs in the filename I get
[0.713335][ T12] imx-sdma 302b.dma-controller: loaded firmware 4.5
early in the boot so I know the initramfs works.
So you could say use the FIT image with the initramfs in its filename
but this isn't the FIT image that gets installed by
packagegroup-core-boot and I can't find out how to use the other FIT
image. I would prefer to bundle the initramfs into the kernel and not
rely on the FIT image mechanism.
I've tried building the kernel with all the INITRAMFS_* variables
commented out and the file sizes are nearly the same, not quite but
nearly. The initramfs is around 4MiB in size due to firmware files,
busybox and the libraries that this requires to perform the
switch_root. This also suggests that CONFIG_INITRAMFS_SOURCE isn't
working.
I've built the kernel with verbose on and see
+
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build/usr/octave-cad-image-initramfs-octave-imx8mnevk.cpio
and also
+ oe_runmake [snip]
CONFIG_INITRAMFS_SOURCE=/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work/octave_imx8mnevk-poky-linux/linux-imx/5.4.24+gitAUTOINC+babac008e5-r0/build/usr/octave-cad-image-initramfs-octave-imx8mnevk.cpio
So it looks like this doesn't work for some reason. I am using NXP's
vendor specific kernel but I don't think they've touched the kernel's
build system. The kernel version is 5.4. The log does contain what
looks like the Makefile actually performing the steps required
GEN Makefile
scripts/kconfig/conf --syncconfig Kconfig
GEN Makefile
CALL
/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work-shared/octave-imx8mnevk/kernel-source/scripts/checksyscalls.sh
CALL
/ws/rufilla/octopus/octave-dunfell/build-release/tmp/work-shared/octave-imx8mnevk/kernel-source/scripts/atomic/check-atomics.sh
CHK include/generated/compile.h
GEN usr/initramfs_data.cpio
AS usr/initramfs_data.o
AR usr/built-in.a
GEN .version
CHK include/generated/compile.h
LD vmlinux.o
MODPOST vmlinux.o
MODINFO modules.builtin.modinfo
LD .tmp_vmlinux1
KSYM.tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM.tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
OBJCOPY arch/arm64/boot/Image
${B}/usr seems ok
drwxr-xr-x 2 martin martin4096 Jan 27 17:19 .
drwxr-xr-x 20 martin martin4096 Jan 27 17:19 ..
-rw-rw-r-- 1 martin martin 146 Jan 27 17:19 built-in.a
-rw-r--r-- 1 martin martin 109 Jan 27 17:19 .built-in.a.cmd
-rwxr-xr-x 1 martin martin 31320 Jan 27 17:14 gen_init_cpio
-rw-r--r-- 1 martin martin6642 Jan 27 17:14 .gen_init_cpio.cmd
-rw-r--r-- 1 martin martin 512 Jan 27 17:14 initramfs_data.cpio
-rw-r--r-- 1 martin martin 188 Jan 27 17:14 .initramfs_data.cpio.cmd
-rw-r--r-- 1 martin martin 142 Jan 27 17:15 .initramfs_data.cpio.d
-rw-rw-r-- 1 martin martin 1504249 Jan 27 17:19 initramfs_data.cpio.gz
-rw-rw-r-- 1 martin martin 389 Jan 27 17:19 .initramfs_data.cpio.gz.cmd
-rw-rw-r-- 1 martin
Re: [yocto] Strange package QA errors
On Thu, Jul 23, 2020 at 4:20 PM Martin Townsend wrote: > > On Thu, Jul 23, 2020 at 3:55 PM Martin Townsend > wrote: > > > > On Thu, Jul 23, 2020 at 3:11 PM Martin Townsend > > wrote: > > > > > > Hi, > > > > > > I've just upgraded to the dunfell release and now get Package QA > > > errors like the following > > > > > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/bin/dbus-daemon > > > contained in package dbus requires > > > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > > > RDEPENDS_dbus? [file-rdeps] > > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/bin/dbus-daemon > > > contained in package dbus requires libsystemd.so.0()(64bit), but no > > > providers found in RDEPENDS_dbus? [file-rdeps] > > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: > > > /usr/lib/libdbus-1.so.3.19.11 contained in package dbus-lib requires > > > libsystemd.so.0()(64bit), but no providers found in RDEPENDS_dbus-lib? > > > [file-rdeps] > > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: > > > /usr/lib/libdbus-1.so.3.19.11 contained in package dbus-lib requires > > > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > > > RDEPENDS_dbus-lib? [file-rdeps] > > > ERROR: dbus-1.12.16-r0 do_package_qa: QA run found fatal errors. > > > Please consider fixing them. > > > ERROR: Logfile of failure stored in: > > > /ws/rufilla/octopus/octave-linux/build/tmp/work/aarch64-fsl-linux/dbus/1.12.16-r0/temp/log.do_package_qa.31770 > > > ERROR: Task > > > (/ws/rufilla/octopus/octave-linux/build/../sources/poky/meta/recipes-core/dbus/dbus_1.12.16.bb:do_package_qa) > > > failed with exit code '1' > > > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA Issue: > > > /usr/sbin/ModemManager contained in package modemmanager requires > > > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > > > RDEPENDS_modemmanager? [file-rdeps] > > > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA Issue: > > > /usr/sbin/ModemManager contained in package modemmanager requires > > > libsystemd.so.0()(64bit), but no providers found in > > > RDEPENDS_modemmanager? [file-rdeps] > > > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA run found fatal > > > errors. Please consider fixing them. > > > ERROR: Logfile of failure stored in: > > > /ws/rufilla/octopus/octave-linux/build/tmp/work/aarch64-fsl-linux/modemmanager/1.12.12-r0/temp/log.do_package_qa.31773 > > > ERROR: Task > > > (/ws/rufilla/octopus/octave-linux/build/../sources/meta-octopus/recipes-connectivity/modemanager/modemmanager_1.12.12.bb:do_package_qa) > > > failed with exit code '1' > > > > > > I've tried adding libsystemd to RDEPENDS but the error message still > > > appears. Thinking it was something to do with my systemd appends I > > > removed it. The above build errors disappeared but then I get similar > > > errors for usbutils this time with libudev. I can't see why the > > > changes I have made to systemd would cause the errors above as > > > libsystemd is built and packaged. I checked and libsystemd.so.0 is in > > > the recipe-sysroot directory for dbus and modemmanager and objdump > > > says that LIBSYSTEMD_209 is defined. > > > > > > Version definitions: > > > 1 0x01 0x0ae55a40 libsystemd.so.0 > > > 2 0x00 0x0562c8b9 LIBSYSTEMD_209 > > > 3 0x00 0x0562c8c1 LIBSYSTEMD_211 > > > LIBSYSTEMD_209 > > > 4 0x00 0x0562c8c3 LIBSYSTEMD_213 > > > LIBSYSTEMD_211 > > > 5 0x00 0x0562c8c4 LIBSYSTEMD_214 > > > LIBSYSTEMD_213 > > > 6 0x00 0x0562c8c6 LIBSYSTEMD_216 > > > LIBSYSTEMD_214 > > > 7 0x00 0x0562c8c7 LIBSYSTEMD_217 > > > LIBSYSTEMD_216 > > > 8 0x00 0x0562c8c9 LIBSYSTEMD_219 > > > LIBSYSTEMD_217 > > > 9 0x00 0x0562c8d0 LIBSYSTEMD_220 > > > LIBSYSTEMD_219 > > > 10 0x00 0x0562c8d1 LIBSYSTEMD_221 > > > LIBSYSTEMD_220 > > > 11 0x00 0x0562c8d2 LIBSYSTEMD_222 > > > LIBSYSTEMD_221 > > > 12 0x00 0x0562c8d6 LIBSYSTEMD_226 > > > LIBSYSTEMD_222 > > > 13 0x00 0x0562c8d7 LIBSYSTEMD_227 > > > LIBSYSTEMD_226 > > > 14 0x00 0x0562c8d9 LIBSYSTEMD_229 > > > LIBSYSTEMD_227 > > > 15 0x00 0x0562c8e0 LIBSYSTEMD_230 > > > LIBSYSTEMD_229 > > > 16 0x00 0x0562c8e1 LIBSYSTEMD_231 > > > LIBSYSTEMD_230 > > > 17 0x00 0x0562c8e2 LIBSYSTEMD_232 > > > LIBSYSTEMD_231 > > >
Re: [yocto] Strange package QA errors
On Thu, Jul 23, 2020 at 3:55 PM Martin Townsend wrote: > > On Thu, Jul 23, 2020 at 3:11 PM Martin Townsend > wrote: > > > > Hi, > > > > I've just upgraded to the dunfell release and now get Package QA > > errors like the following > > > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/bin/dbus-daemon > > contained in package dbus requires > > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > > RDEPENDS_dbus? [file-rdeps] > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/bin/dbus-daemon > > contained in package dbus requires libsystemd.so.0()(64bit), but no > > providers found in RDEPENDS_dbus? [file-rdeps] > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: > > /usr/lib/libdbus-1.so.3.19.11 contained in package dbus-lib requires > > libsystemd.so.0()(64bit), but no providers found in RDEPENDS_dbus-lib? > > [file-rdeps] > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: > > /usr/lib/libdbus-1.so.3.19.11 contained in package dbus-lib requires > > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > > RDEPENDS_dbus-lib? [file-rdeps] > > ERROR: dbus-1.12.16-r0 do_package_qa: QA run found fatal errors. > > Please consider fixing them. > > ERROR: Logfile of failure stored in: > > /ws/rufilla/octopus/octave-linux/build/tmp/work/aarch64-fsl-linux/dbus/1.12.16-r0/temp/log.do_package_qa.31770 > > ERROR: Task > > (/ws/rufilla/octopus/octave-linux/build/../sources/poky/meta/recipes-core/dbus/dbus_1.12.16.bb:do_package_qa) > > failed with exit code '1' > > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA Issue: > > /usr/sbin/ModemManager contained in package modemmanager requires > > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > > RDEPENDS_modemmanager? [file-rdeps] > > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA Issue: > > /usr/sbin/ModemManager contained in package modemmanager requires > > libsystemd.so.0()(64bit), but no providers found in > > RDEPENDS_modemmanager? [file-rdeps] > > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA run found fatal > > errors. Please consider fixing them. > > ERROR: Logfile of failure stored in: > > /ws/rufilla/octopus/octave-linux/build/tmp/work/aarch64-fsl-linux/modemmanager/1.12.12-r0/temp/log.do_package_qa.31773 > > ERROR: Task > > (/ws/rufilla/octopus/octave-linux/build/../sources/meta-octopus/recipes-connectivity/modemanager/modemmanager_1.12.12.bb:do_package_qa) > > failed with exit code '1' > > > > I've tried adding libsystemd to RDEPENDS but the error message still > > appears. Thinking it was something to do with my systemd appends I > > removed it. The above build errors disappeared but then I get similar > > errors for usbutils this time with libudev. I can't see why the > > changes I have made to systemd would cause the errors above as > > libsystemd is built and packaged. I checked and libsystemd.so.0 is in > > the recipe-sysroot directory for dbus and modemmanager and objdump > > says that LIBSYSTEMD_209 is defined. > > > > Version definitions: > > 1 0x01 0x0ae55a40 libsystemd.so.0 > > 2 0x00 0x0562c8b9 LIBSYSTEMD_209 > > 3 0x00 0x0562c8c1 LIBSYSTEMD_211 > > LIBSYSTEMD_209 > > 4 0x00 0x0562c8c3 LIBSYSTEMD_213 > > LIBSYSTEMD_211 > > 5 0x00 0x0562c8c4 LIBSYSTEMD_214 > > LIBSYSTEMD_213 > > 6 0x00 0x0562c8c6 LIBSYSTEMD_216 > > LIBSYSTEMD_214 > > 7 0x00 0x0562c8c7 LIBSYSTEMD_217 > > LIBSYSTEMD_216 > > 8 0x00 0x0562c8c9 LIBSYSTEMD_219 > > LIBSYSTEMD_217 > > 9 0x00 0x0562c8d0 LIBSYSTEMD_220 > > LIBSYSTEMD_219 > > 10 0x00 0x0562c8d1 LIBSYSTEMD_221 > > LIBSYSTEMD_220 > > 11 0x00 0x0562c8d2 LIBSYSTEMD_222 > > LIBSYSTEMD_221 > > 12 0x00 0x0562c8d6 LIBSYSTEMD_226 > > LIBSYSTEMD_222 > > 13 0x00 0x0562c8d7 LIBSYSTEMD_227 > > LIBSYSTEMD_226 > > 14 0x00 0x0562c8d9 LIBSYSTEMD_229 > > LIBSYSTEMD_227 > > 15 0x00 0x0562c8e0 LIBSYSTEMD_230 > > LIBSYSTEMD_229 > > 16 0x00 0x0562c8e1 LIBSYSTEMD_231 > > LIBSYSTEMD_230 > > 17 0x00 0x0562c8e2 LIBSYSTEMD_232 > > LIBSYSTEMD_231 > > 18 0x00 0x0562c8e3 LIBSYSTEMD_233 > > LIBSYSTEMD_232 > > 19 0x00 0x0562c8e4 LIBSYSTEMD_234 > > LIBSYSTEMD_233 > > 20 0x00 0x0562c8e6 LIBSYSTEMD_236 > > LIBSYSTEMD_234 > > 21 0x00 0x0562c8e7 LIBSYSTEMD_237 > > LIBSYSTEMD_236 > > 22 0x00 0x0562c8e8 LIBSYSTEMD_238 > > LIBSYSTEMD_237 > > 23 0x00 0x0562c8e9 LIBSYSTEMD_239 > > LIBSYSTEMD_238 > > 24 0x00 0x0562c8f0 LIBSYSTEMD_240 > > LIBSYSTEMD_239 > > 25 0x00 0x0562c8f1 LIBSYSTEMD_
Re: [yocto] Strange package QA errors
On Thu, Jul 23, 2020 at 3:11 PM Martin Townsend wrote: > > Hi, > > I've just upgraded to the dunfell release and now get Package QA > errors like the following > > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/bin/dbus-daemon > contained in package dbus requires > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > RDEPENDS_dbus? [file-rdeps] > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/bin/dbus-daemon > contained in package dbus requires libsystemd.so.0()(64bit), but no > providers found in RDEPENDS_dbus? [file-rdeps] > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: > /usr/lib/libdbus-1.so.3.19.11 contained in package dbus-lib requires > libsystemd.so.0()(64bit), but no providers found in RDEPENDS_dbus-lib? > [file-rdeps] > ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: > /usr/lib/libdbus-1.so.3.19.11 contained in package dbus-lib requires > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > RDEPENDS_dbus-lib? [file-rdeps] > ERROR: dbus-1.12.16-r0 do_package_qa: QA run found fatal errors. > Please consider fixing them. > ERROR: Logfile of failure stored in: > /ws/rufilla/octopus/octave-linux/build/tmp/work/aarch64-fsl-linux/dbus/1.12.16-r0/temp/log.do_package_qa.31770 > ERROR: Task > (/ws/rufilla/octopus/octave-linux/build/../sources/poky/meta/recipes-core/dbus/dbus_1.12.16.bb:do_package_qa) > failed with exit code '1' > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA Issue: > /usr/sbin/ModemManager contained in package modemmanager requires > libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in > RDEPENDS_modemmanager? [file-rdeps] > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA Issue: > /usr/sbin/ModemManager contained in package modemmanager requires > libsystemd.so.0()(64bit), but no providers found in > RDEPENDS_modemmanager? [file-rdeps] > ERROR: modemmanager-1.12.12-r0 do_package_qa: QA run found fatal > errors. Please consider fixing them. > ERROR: Logfile of failure stored in: > /ws/rufilla/octopus/octave-linux/build/tmp/work/aarch64-fsl-linux/modemmanager/1.12.12-r0/temp/log.do_package_qa.31773 > ERROR: Task > (/ws/rufilla/octopus/octave-linux/build/../sources/meta-octopus/recipes-connectivity/modemanager/modemmanager_1.12.12.bb:do_package_qa) > failed with exit code '1' > > I've tried adding libsystemd to RDEPENDS but the error message still > appears. Thinking it was something to do with my systemd appends I > removed it. The above build errors disappeared but then I get similar > errors for usbutils this time with libudev. I can't see why the > changes I have made to systemd would cause the errors above as > libsystemd is built and packaged. I checked and libsystemd.so.0 is in > the recipe-sysroot directory for dbus and modemmanager and objdump > says that LIBSYSTEMD_209 is defined. > > Version definitions: > 1 0x01 0x0ae55a40 libsystemd.so.0 > 2 0x00 0x0562c8b9 LIBSYSTEMD_209 > 3 0x00 0x0562c8c1 LIBSYSTEMD_211 > LIBSYSTEMD_209 > 4 0x00 0x0562c8c3 LIBSYSTEMD_213 > LIBSYSTEMD_211 > 5 0x00 0x0562c8c4 LIBSYSTEMD_214 > LIBSYSTEMD_213 > 6 0x00 0x0562c8c6 LIBSYSTEMD_216 > LIBSYSTEMD_214 > 7 0x00 0x0562c8c7 LIBSYSTEMD_217 > LIBSYSTEMD_216 > 8 0x00 0x0562c8c9 LIBSYSTEMD_219 > LIBSYSTEMD_217 > 9 0x00 0x0562c8d0 LIBSYSTEMD_220 > LIBSYSTEMD_219 > 10 0x00 0x0562c8d1 LIBSYSTEMD_221 > LIBSYSTEMD_220 > 11 0x00 0x0562c8d2 LIBSYSTEMD_222 > LIBSYSTEMD_221 > 12 0x00 0x0562c8d6 LIBSYSTEMD_226 > LIBSYSTEMD_222 > 13 0x00 0x0562c8d7 LIBSYSTEMD_227 > LIBSYSTEMD_226 > 14 0x00 0x0562c8d9 LIBSYSTEMD_229 > LIBSYSTEMD_227 > 15 0x00 0x0562c8e0 LIBSYSTEMD_230 > LIBSYSTEMD_229 > 16 0x00 0x0562c8e1 LIBSYSTEMD_231 > LIBSYSTEMD_230 > 17 0x00 0x0562c8e2 LIBSYSTEMD_232 > LIBSYSTEMD_231 > 18 0x00 0x0562c8e3 LIBSYSTEMD_233 > LIBSYSTEMD_232 > 19 0x00 0x0562c8e4 LIBSYSTEMD_234 > LIBSYSTEMD_233 > 20 0x00 0x0562c8e6 LIBSYSTEMD_236 > LIBSYSTEMD_234 > 21 0x00 0x0562c8e7 LIBSYSTEMD_237 > LIBSYSTEMD_236 > 22 0x00 0x0562c8e8 LIBSYSTEMD_238 > LIBSYSTEMD_237 > 23 0x00 0x0562c8e9 LIBSYSTEMD_239 > LIBSYSTEMD_238 > 24 0x00 0x0562c8f0 LIBSYSTEMD_240 > LIBSYSTEMD_239 > 25 0x00 0x0562c8f1 LIBSYSTEMD_241 > LIBSYSTEMD_240 > 26 0x00 0x0562c8f3 LIBSYSTEMD_243 > LIBSYSTEMD_241 > > Is the file-rdeps check broken on aarch64/dunfell? I'm building for > an i.MX EVK so I have the meta-freescale layer. > > The build configuration looks like this > Build Configuration: > BB_VERSION = "1.46.0" > BUILD_SYS= "x86_64-linux" > NATIVELSBSTRING = "universal" > TARGET_SYS = "aarch64-fsl-linux" > MACHINE = "imx8mnevk" > DISTRO = "oc
[yocto] Strange package QA errors
Hi, I've just upgraded to the dunfell release and now get Package QA errors like the following ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/bin/dbus-daemon contained in package dbus requires libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in RDEPENDS_dbus? [file-rdeps] ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/bin/dbus-daemon contained in package dbus requires libsystemd.so.0()(64bit), but no providers found in RDEPENDS_dbus? [file-rdeps] ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/lib/libdbus-1.so.3.19.11 contained in package dbus-lib requires libsystemd.so.0()(64bit), but no providers found in RDEPENDS_dbus-lib? [file-rdeps] ERROR: dbus-1.12.16-r0 do_package_qa: QA Issue: /usr/lib/libdbus-1.so.3.19.11 contained in package dbus-lib requires libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in RDEPENDS_dbus-lib? [file-rdeps] ERROR: dbus-1.12.16-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. ERROR: Logfile of failure stored in: /ws/rufilla/octopus/octave-linux/build/tmp/work/aarch64-fsl-linux/dbus/1.12.16-r0/temp/log.do_package_qa.31770 ERROR: Task (/ws/rufilla/octopus/octave-linux/build/../sources/poky/meta/recipes-core/dbus/dbus_1.12.16.bb:do_package_qa) failed with exit code '1' ERROR: modemmanager-1.12.12-r0 do_package_qa: QA Issue: /usr/sbin/ModemManager contained in package modemmanager requires libsystemd.so.0(LIBSYSTEMD_209)(64bit), but no providers found in RDEPENDS_modemmanager? [file-rdeps] ERROR: modemmanager-1.12.12-r0 do_package_qa: QA Issue: /usr/sbin/ModemManager contained in package modemmanager requires libsystemd.so.0()(64bit), but no providers found in RDEPENDS_modemmanager? [file-rdeps] ERROR: modemmanager-1.12.12-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. ERROR: Logfile of failure stored in: /ws/rufilla/octopus/octave-linux/build/tmp/work/aarch64-fsl-linux/modemmanager/1.12.12-r0/temp/log.do_package_qa.31773 ERROR: Task (/ws/rufilla/octopus/octave-linux/build/../sources/meta-octopus/recipes-connectivity/modemanager/modemmanager_1.12.12.bb:do_package_qa) failed with exit code '1' I've tried adding libsystemd to RDEPENDS but the error message still appears. Thinking it was something to do with my systemd appends I removed it. The above build errors disappeared but then I get similar errors for usbutils this time with libudev. I can't see why the changes I have made to systemd would cause the errors above as libsystemd is built and packaged. I checked and libsystemd.so.0 is in the recipe-sysroot directory for dbus and modemmanager and objdump says that LIBSYSTEMD_209 is defined. Version definitions: 1 0x01 0x0ae55a40 libsystemd.so.0 2 0x00 0x0562c8b9 LIBSYSTEMD_209 3 0x00 0x0562c8c1 LIBSYSTEMD_211 LIBSYSTEMD_209 4 0x00 0x0562c8c3 LIBSYSTEMD_213 LIBSYSTEMD_211 5 0x00 0x0562c8c4 LIBSYSTEMD_214 LIBSYSTEMD_213 6 0x00 0x0562c8c6 LIBSYSTEMD_216 LIBSYSTEMD_214 7 0x00 0x0562c8c7 LIBSYSTEMD_217 LIBSYSTEMD_216 8 0x00 0x0562c8c9 LIBSYSTEMD_219 LIBSYSTEMD_217 9 0x00 0x0562c8d0 LIBSYSTEMD_220 LIBSYSTEMD_219 10 0x00 0x0562c8d1 LIBSYSTEMD_221 LIBSYSTEMD_220 11 0x00 0x0562c8d2 LIBSYSTEMD_222 LIBSYSTEMD_221 12 0x00 0x0562c8d6 LIBSYSTEMD_226 LIBSYSTEMD_222 13 0x00 0x0562c8d7 LIBSYSTEMD_227 LIBSYSTEMD_226 14 0x00 0x0562c8d9 LIBSYSTEMD_229 LIBSYSTEMD_227 15 0x00 0x0562c8e0 LIBSYSTEMD_230 LIBSYSTEMD_229 16 0x00 0x0562c8e1 LIBSYSTEMD_231 LIBSYSTEMD_230 17 0x00 0x0562c8e2 LIBSYSTEMD_232 LIBSYSTEMD_231 18 0x00 0x0562c8e3 LIBSYSTEMD_233 LIBSYSTEMD_232 19 0x00 0x0562c8e4 LIBSYSTEMD_234 LIBSYSTEMD_233 20 0x00 0x0562c8e6 LIBSYSTEMD_236 LIBSYSTEMD_234 21 0x00 0x0562c8e7 LIBSYSTEMD_237 LIBSYSTEMD_236 22 0x00 0x0562c8e8 LIBSYSTEMD_238 LIBSYSTEMD_237 23 0x00 0x0562c8e9 LIBSYSTEMD_239 LIBSYSTEMD_238 24 0x00 0x0562c8f0 LIBSYSTEMD_240 LIBSYSTEMD_239 25 0x00 0x0562c8f1 LIBSYSTEMD_241 LIBSYSTEMD_240 26 0x00 0x0562c8f3 LIBSYSTEMD_243 LIBSYSTEMD_241 Is the file-rdeps check broken on aarch64/dunfell? I'm building for an i.MX EVK so I have the meta-freescale layer. The build configuration looks like this Build Configuration: BB_VERSION = "1.46.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "aarch64-fsl-linux" MACHINE = "imx8mnevk" DISTRO = "octave-os" DISTRO_VERSION = "1.0.0" TUNE_FEATURES= "aarch64 cortexa53 crc crypto" TARGET_FPU = "" meta meta-poky= "dunfell:c9ecbbc87a1f401ab040fde735a20ff05cb7bcd4" meta-freescale = "dunfell:901b192ff8652236607f423386aee496e3ae2730" meta-oe meta-networking meta-python = "dunfell:cc6fc6b1641ab23089c1e3bba11e0c6394f0867c" I can send more information if required, or happy to run any commands to help debug this problem. I'll use INSANE_SKIP for the moment to get past this but would like to get to the bottom of this in case there is a real problem. Many Thanks, Martin. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to
[linux-yocto] linux-yocto-tiny and mips
Hi, I've just tried building linux-yocto-tiny for qemumips and found that it's not supported. I don't mind adding the support but I before doing so I just wanted to check if there is a good reason why it's not there? ie the changes made to the kernel aren't compatible with MIPS. Many Thanks, Martin. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8392): https://lists.yoctoproject.org/g/linux-yocto/message/8392 Mute This Topic: https://lists.yoctoproject.org/mt/71535463/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Problem build SDK with Zeus release
On Tue, Dec 17, 2019 at 3:17 PM Martin Townsend wrote: > Hi, > > I've upgraded to Zeus from Rocko but can't seem to get the SDK to build > that built fine in Rocko. I'm using dpkg which I think has something to do > with it. Here is the error message and it mentions rpm so I'm wondering if > there is some problem with using the debian package manager and building > the sdk. > > Any help would be greatly appreciated, > Martin. > > > Identifying dependency loops (this may take a short while)... > > ERROR: > Dependency loop #1 found: > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_compile > (dependent Tasks ['ncurses_6.1+20190803.bb:do_configure']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_install > (dependent Tasks ['pseudo_git.bb:do_populate_sysroot', > 'ncurses_6.1+20190803.bb:do_compile']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_populate_sysroot > (dependent Tasks ['ncurses_6.1+20190803.bb:do_install', > 'binutils-crosssdk_2.32.bb:do_populate_sysroot']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_prepare_recipe_sysroot > (dependent Tasks ['gcc-runtime_9.2.bb:do_populate_sysroot', > 'pkgconfig_git.bb:do_populate_sysroot', > 'gcc-crosssdk_9.2.bb:do_populate_sysroot', > 'gnu-config_git.bb:do_populate_sysroot', 'zlib_1.2.11.bb:do_populate_sysroot', > 'autoconf_2.69.bb:do_populate_sysroot', 'bzip2_1.0.8.bb:do_populate_sysroot', > 'perl_5.30.0.bb:do_populate_sysroot', 'chrpath_0.16.bb:do_populate_sysroot', > 'xz_5.2.4.bb:do_populate_sysroot', 'automake_1.16.1.bb:do_populate_sysroot', > 'ncurses_6.1+20190803.bb:do_populate_sysroot', 'dpkg_1.19.7.bb:do_fetch', > 'gettext_0.19.8.1.bb:do_populate_sysroot', > 'glibc_2.30.bb:do_populate_sysroot', > 'perl_5.30.0.bb:do_populate_sysroot', 'libtool-native_2.4.6.bb: > do_populate_sysroot']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_configure > (dependent Tasks ['dpkg_1.19.7.bb:do_patch', 'dpkg_1.19.7.bb: > do_prepare_recipe_sysroot']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_compile > (dependent Tasks ['dpkg_1.19.7.bb:do_configure']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_install > (dependent Tasks ['pseudo_git.bb:do_populate_sysroot', 'dpkg_1.19.7.bb: > do_compile']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_populate_sysroot > (dependent Tasks ['binutils-crosssdk_2.32.bb:do_populate_sysroot', > 'dpkg_1.19.7.bb:do_install']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_prepare_recipe_sysroot > (dependent Tasks ['gcc-runtime_9.2.bb:do_populate_sysroot', > 'ncurses_6.1+20190803.bb:do_populate_sysroot', > 'dpkg_1.19.7.bb:do_populate_sysroot', > 'ncurses_6.1+20190803.bb:do_fetch', 'gnu-config_git.bb:do_populate_sysroot', > 'pkgconfig_git.bb:do_populate_sysroot', > 'autoconf_2.69.bb:do_populate_sysroot', > 'gcc-crosssdk_9.2.bb:do_populate_sysroot', > 'chrpath_0.16.bb:do_populate_sysroot', > 'automake_1.16.1.bb:do_populate_sysroot', 'glibc_2.30.bb:do_populate_sysroot', > 'libtool-native_2.4.6.bb:do_populate_sysroot']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_configure > (dependent Tasks ['ncurses_6.1+20190803.bb:do_prepare_recipe_sysroot', > 'ncurses_6.1+20190803.bb:do_patch']) > > Dependency loop #2 found: > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_package > (dependent Tasks ['gcc-runtime_9.2.bb:do_packagedata', > 'rpm_4.14.2.1.bb:do_populate_sysroot', > 'ncurses_6.1+20190803.bb:do_install', 'pseudo_git.bb:do_populate_sysroot', > 'dwarfsrcfiles.bb:do_populate_sysroot', 'glibc_2.30.bb:do_packagedata', > 'dpkg_1.19.7.bb:do_packagedata']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_packagedata > (dependent Tasks ['ncurses_6.1+20190803.bb:do_package']) > Task > virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_package > (dependent Tasks ['gcc-runtime_9.2.bb:do_packagedata', > 'rpm_4.14.2.1.bb:do_populate_sysroot', > 'dpkg_1.19.7.bb:do_install', 'xz_5.2.4.bb:do_packagedata', > 'zlib_1.2.11.bb
[yocto] Problem build SDK with Zeus release
Hi, I've upgraded to Zeus from Rocko but can't seem to get the SDK to build that built fine in Rocko. I'm using dpkg which I think has something to do with it. Here is the error message and it mentions rpm so I'm wondering if there is some problem with using the debian package manager and building the sdk. Any help would be greatly appreciated, Martin. Identifying dependency loops (this may take a short while)... ERROR: Dependency loop #1 found: Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_compile (dependent Tasks ['ncurses_6.1+20190803.bb:do_configure']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_install (dependent Tasks ['pseudo_git.bb:do_populate_sysroot', 'ncurses_6.1+20190803.bb:do_compile']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_populate_sysroot (dependent Tasks ['ncurses_6.1+20190803.bb:do_install', 'binutils-crosssdk_2.32.bb:do_populate_sysroot']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_prepare_recipe_sysroot (dependent Tasks ['gcc-runtime_9.2.bb:do_populate_sysroot', 'pkgconfig_git.bb:do_populate_sysroot', 'gcc-crosssdk_9.2.bb:do_populate_sysroot', 'gnu-config_git.bb:do_populate_sysroot', 'zlib_1.2.11.bb:do_populate_sysroot', 'autoconf_2.69.bb:do_populate_sysroot', 'bzip2_1.0.8.bb:do_populate_sysroot', 'perl_5.30.0.bb:do_populate_sysroot', 'chrpath_0.16.bb:do_populate_sysroot', 'xz_5.2.4.bb:do_populate_sysroot', 'automake_1.16.1.bb:do_populate_sysroot', 'ncurses_6.1+20190803.bb:do_populate_sysroot', 'dpkg_1.19.7.bb:do_fetch', 'gettext_0.19.8.1.bb:do_populate_sysroot', 'glibc_2.30.bb:do_populate_sysroot', 'perl_5.30.0.bb:do_populate_sysroot', 'libtool-native_2.4.6.bb: do_populate_sysroot']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_configure (dependent Tasks ['dpkg_1.19.7.bb:do_patch', 'dpkg_1.19.7.bb: do_prepare_recipe_sysroot']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_compile (dependent Tasks ['dpkg_1.19.7.bb:do_configure']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_install (dependent Tasks ['pseudo_git.bb:do_populate_sysroot', 'dpkg_1.19.7.bb: do_compile']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_populate_sysroot (dependent Tasks ['binutils-crosssdk_2.32.bb:do_populate_sysroot', 'dpkg_1.19.7.bb:do_install']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_prepare_recipe_sysroot (dependent Tasks ['gcc-runtime_9.2.bb:do_populate_sysroot', 'ncurses_6.1+20190803.bb:do_populate_sysroot', 'dpkg_1.19.7.bb:do_populate_sysroot', 'ncurses_6.1+20190803.bb:do_fetch', 'gnu-config_git.bb:do_populate_sysroot', 'pkgconfig_git.bb:do_populate_sysroot', 'autoconf_2.69.bb:do_populate_sysroot', 'gcc-crosssdk_9.2.bb:do_populate_sysroot', 'chrpath_0.16.bb:do_populate_sysroot', 'automake_1.16.1.bb:do_populate_sysroot', 'glibc_2.30.bb:do_populate_sysroot', 'libtool-native_2.4.6.bb:do_populate_sysroot']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_configure (dependent Tasks ['ncurses_6.1+20190803.bb:do_prepare_recipe_sysroot', 'ncurses_6.1+20190803.bb:do_patch']) Dependency loop #2 found: Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_package (dependent Tasks ['gcc-runtime_9.2.bb:do_packagedata', 'rpm_4.14.2.1.bb:do_populate_sysroot', 'ncurses_6.1+20190803.bb:do_install', 'pseudo_git.bb:do_populate_sysroot', 'dwarfsrcfiles.bb:do_populate_sysroot', 'glibc_2.30.bb:do_packagedata', 'dpkg_1.19.7.bb:do_packagedata']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-core/ncurses/ncurses_6.1+20190803.bb:do_packagedata (dependent Tasks ['ncurses_6.1+20190803.bb:do_package']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_package (dependent Tasks ['gcc-runtime_9.2.bb:do_packagedata', 'rpm_4.14.2.1.bb:do_populate_sysroot', 'dpkg_1.19.7.bb:do_install', 'xz_5.2.4.bb:do_packagedata', 'zlib_1.2.11.bb:do_packagedata', 'ncurses_6.1+20190803.bb:do_packagedata', 'pseudo_git.bb:do_populate_sysroot', 'perl_5.30.0.bb:do_packagedata', 'bzip2_1.0.8.bb:do_packagedata', 'dwarfsrcfiles.bb:do_populate_sysroot', 'glibc_2.30.bb:do_packagedata']) Task virtual:nativesdk:/ws/sps/bia-zeus/build/../yocto/poky/meta/recipes-devtools/dpkg/dpkg_1.19.7.bb:do_packagedata (dependent Tasks ['dpkg_1.19.7.bb:do_package']) Dependency loop #3 found: Task
