Is there any way to disable do_package_qa step during bitbake
Actually I have a precompiled binary which I want to copy to my rootfs. I have tried install as well as cp in the do_install section of my recipe.
In both the cases, I am getting QA issue which complains about libQt5Qml.so and libQt5Quick.so not being found in RDEPENDS.
I have tried INSANE_SKIP_${PN} , RDEPENDS_${PN} and DEPENDS to suppress the errors but I am not able to do so.
Is there any way with which I can compile my recipe ?
Recipe
DESCRIPTION = "..."
LICENSE = "CLOSED"
RDEPENDS_${PN} = "qtbase"
SRC_URI = "file://hello.c \
file://basic \
"
S = "${WORKDIR}"
do_compile() {
${CC} hello.c -o hello
}
do_install() {
install -d ${D}/opt/mybin/
install -m 0755 hello ${D}/opt/mybin/
install -m 0755 basic ${D}/opt/mybin/
}
FILES_${PN} = "/opt/mybin/"
INSANE_SKIP_${PN} = "ldflags"
Error
ERROR: my-binary-1.0-r0 do_package_qa: QA Issue: /opt/mybin/basic contained in package my-binary requires libQt5Qml.so.5(Qt_5), but no providers found in RDEPENDS_my-binary? [file-rdeps]
ERROR: my-binary-1.0-r0 do_package_qa: QA Issue: /opt/mybin/basic contained in package my-binary requires libQt5Quick.so.5(Qt_5), but no providers found in RDEPENDS_my-binary? [file-rdeps]
INSANE_SKIP_${PN} = "file-rdeps" might help to fix the error.
Reported issue is something similar to below link
Errors including shared prebuilt libraries in petalinux
Maybe adding
RDEPENDS_${PN} += " libQt5Qml.so.5(Qt_5) libQt5Quick.so.5(Qt_5)"
to your recipe it will solve the QA issue. Lets try.
Related
Parameters:
source = x86_x64 windows 10 or x86_x64 linux (ubuntu wsl)
target = armv5te linux
target_type = cdylib
target_glibc = 2.24
language = rust
build_tool = cargo
compiler = rustc
(The target is a Lego Mindstorm running a linux image from Ev3dev)
Cargo Configuration:
[package]
name = "ev3"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
jni = "0.19"
ev3dev-lang-rust = { version = "0.12.1", features=["screen"]}
jni_proc_macro= {path= "./jni_proc_macro"}
[lib]
crate-type= ["cdylib"]
[workspace]
members= ["jni_proc_macro"]
Build Configuration:
[build]
target = "armv5te-unknown-linux-gnueabi"
[target.armv5te-unknown-linux-gnueabi]
linker = "rust-lld"
Build Error:
error: linking with `rust-lld` failed: exit code: 1
|
= note: {...}
= note: rust-lld: error: unable to find library -lgcc_s
rust-lld: error: unable to find library -lutil
rust-lld: error: unable to find library -lrt
rust-lld: error: unable to find library -lpthread
rust-lld: error: unable to find library -lm
rust-lld: error: unable to find library -ldl
rust-lld: error: unable to find library -lc
error: could not compile `ev3` due to previous error
As the error suggests the linker is missing libraries. I found no clear solution where I can download and or provide these dependencies.
My question is, A is there a diffrent way to build this successfully or B how do I solve these dependencies.
The result needs to be a shared library (.so) for linux and armv5te
Requirements
wsl or linux installed
cargo and rustc installed
(everthing is done in wsl/linux)
Prep/Build
Install cross on cargo
cargo install cross --git https://github.com/cross-rs/cross
Install docker
Clone the cross repository
Navigate into the docker folder
Create a new file with the name "Dockerfile.armv5te-unknown-linux-gnueabi-cross"
Paste this in the new file:
FROM ubuntu:16.04
ARG DEBIAN_FRONTEND=noninteractive
COPY common.sh lib.sh /
RUN /common.sh
COPY cmake.sh /
RUN /cmake.sh
COPY xargo.sh /
RUN /xargo.sh
RUN apt-get update && apt-get install --assume-yes --no-install-recommends \
g++-arm-linux-gnueabi \
crossbuild-essential-armel \
libc6-dev-armel-cross
COPY deny-debian-packages.sh /
RUN TARGET_ARCH=armel /deny-debian-packages.sh \
binutils \
binutils-arm-linux-gnueabi
# Qemu is disabled since we've changed the scripts to require newer Python versions.
#COPY qemu.sh /
#RUN /qemu.sh arm
COPY qemu-runner base-runner.sh /
ENV CROSS_TOOLCHAIN_PREFIX=arm-linux-gnueabi-
ENV CROSS_SYSROOT=/usr/arm-linux-gnueabi
ENV CARGO_TARGET_ARMV5TE_UNKNOWN_LINUX_GNUEABI_LINKER="$CROSS_TOOLCHAIN_PREFIX"gcc \
CARGO_TARGET_ARMV5TE_UNKNOWN_LINUX_GNUEABI_RUNNER="/qemu-runner arm" \
AR_armv5te_unknown_linux_gnueabi="$CROSS_TOOLCHAIN_PREFIX"ar \
CC_armv5te_unknown_linux_gnueabi="$CROSS_TOOLCHAIN_PREFIX"gcc \
CXX_armv5te_unknown_linux_gnueabi="$CROSS_TOOLCHAIN_PREFIX"g++ \
BINDGEN_EXTRA_CLANG_ARGS_armv5te_unknown_linux_gnueabi="--sysroot=$CROSS_SYSROOT" \
QEMU_LD_PREFIX="$CROSS_SYSROOT" \
RUST_TEST_THREADS=1 \
PKG_CONFIG_PATH="/usr/lib/arm-linux-gnueabi/pkgconfig/:${PKG_CONFIG_PATH}"
Make sure the project uses "LF" newlines. if not this fixes it.
Compile the custom cross/docker build using the following command in the root of the cloned repository:
cargo build-docker-image armv5te-unknown-linux-gnueabi-cross
This will create a new docker image that will be used to compile the rust code.
Then navigate to your target project folder and run:
export CROSS_TARGET_ARMV5TE_UNKNOWN_LINUX_GNUEABI_IMAGE=ghcr.io/cross-rs/armv5te-unknown-linux-gnueabi-cross:local
(Do not close this terminal)
Now add the following to the Cargo.toml file:
[package.metadata.cross.build]
default-target = "armv5te-unknown-linux-gnueabi"
now you can run:
cross build
Many cargo options like "--release" can be used (for more info have a look at cross in the credits)
Credits
MeetTitan(Stackoverflow) who recomended me to use cross
Cross project(GitHub) which powers the whole solution
Custom cross version discussion(Cross Github)
Alexhuszagh(Cross Github) who showed me how to build a custom cross version
Emilgardis(Cross Github) who explained the newline bug
I have a C file binary to add as custom layer in the yocto and run in qemu. I have created layer using bitbake-layers create-layer meta-custLayer and added using bitbake-layers add-layer meta-custLayer. The file tree of meta-custLayer is as:
The example_0.1.bb file has the following:
SUMMARY = "bitbake-layers recipe"
DESCRIPTION = "Recipe created by bitbake-layers"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://threading.c"
S = "${WORKDIR}"
TARGET_CC_ARCH += "${LDFLAGS}"
do_compile(){
$(CC) threading.c -o threads -lpthreads
}
do_install(){
install -d ${D}${bindir}
install -m 0755 threads
${D}${bindir}s
}
When the command bitbake example is executed, this is the output:
ERROR: example-0.1-r0 do_compile: Execution of '/home/sajil/edm_yocto/sources/poky/build/tmp/work/core2-64-poky-linux/example/0.1-r0/temp/run.do_compile.1806553' failed with exit code 127:
/home/sajil/edm_yocto/sources/poky/build/tmp/work/core2-64-poky-linux/example/0.1-r0/temp/run.do_compile.1806553: 99: CC: not found
/home/sajil/edm_yocto/sources/poky/build/tmp/work/core2-64-poky-linux/example/0.1-r0/temp/run.do_compile.1806553: 99: threading.c: not found
WARNING: exit code 127 from a shell command.
when bitbake core-image-minimal is executed, terminal shows that threads is unbuildable and runs into error:
ERROR: Nothing RPROVIDES 'threads' (but /home/sajil/edm_yocto/sources/poky/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'threads' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['threads']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 'threads']
I checked the path of the custom layer directory, being correct. I am clueless about the errors I am confronting.
For now my task is to run the C-file (adding it as a layer) on QEMU. I am unable to build the image for the same.
I would appreciate some help and insights!
There is multiple issues on your recipe:
Your do_compile command does not indicate where to find your .c file
You should use ${CC} instead of $(CC)
lpthread does not end with and s
do_compile() {
${CC} ${S}/threading.c -o ${S}/threads -lpthread
}
Your do_install does not provide the correct path to your binary:
do_install() {
install -d ${D}${bindir}
install -m 0755 ${WORKDIR}/threads ${D}${bindir}
}
At the end you should populate the packages:
FILES_${PN} = "${bindir}"
Edit about threads unbuildable:
threads is unbuildable because the recipe does not mention that the package is threads.
Here you have some options:
Rename your recipe to threads_0.1.bb (I recommend you to use a less generic name)
use the PACKAGES variable in your recipe. You will need to modify the FILES_* variable too. (a bit complicated if you are new to Yocto)
Use the current recipe name, and change the IMAGE_INSTALL += "threads" to IMAGE_INSTALL += "example"
For the past couple of days I have been trying to generate a viable CMake SDK with Yocto Project. I'm trying to generate SDK based on an image file which is given below:
#To build SDK, use bitbake meta-toolchain
DESCRIPTION = "Embeddev-LXDE image."
LICENSE="CLOSED"
IMAGE_INSTALL = "packagegroup-core-boot \
packagegroup-core-x11 \
packagegroup-lxde-base \
kernel-modules \
"
IMAGE_INSTALL_append = " nano git cmake qtbase qtchooser dbus packagegroup-core-ssh-openssh xterm"
#Framebuffer driver for tft
IMAGE_INSTALL_append = " xf86-video-fbdev"
IMAGE_INSTALL_append = " apt dpkg sudo tzdata glibc-utils localedef networkmanager pointercal xinit xkeyboard-config base-passwd liberation-fonts pkgconfig"
IMAGE_INSTALL_append = " wiringpi"
#Maybe consider connman instead of networkmanager
#vc-graphics is problematic with userland..
inherit populate_sdk
## SDK stuff, to build sdk use bitbake rpi-embeddev-lxde-image -c populate_sdk
# Add all static packages: SDKIMAGE_FEATURES += "staticdev-pkgs"
SDKIMAGE_FEATURES += "staticdev-pkgs"
SDKIMAGE_FEATURES += "dev-pkgs"
TOOLCHAIN_TARGET_TASK_append = " wiringpi-dev"
TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake"
##
inherit distro_features_check
REQUIRED_DISTRO_FEATURES = "x11"
IMAGE_LINGUAS ?= " "
LICENSE = "MIT"
export IMAGE_BASENAME = "rpi-embeddev-lxde-image"
inherit core-image
ENABLE_SPI_BUS = "1"
ENABLE_I2C = "1"
# qtwebengine qtwebkit ...
do_image_prepend() {
}
I create my SDK with bitbake rpi-embeddev-lxde-image -c populate_sdk.
I would like to describe the exact problem. The problem is that nativesdk-cmake is not correctly installed in the SDK. Cmake 3.10.2 recipe gives:
do_install_append_class-nativesdk() {
mkdir -p ${D}${datadir}/cmake
install -m 644 ${WORKDIR}/OEToolchainConfig.cmake ${D}${datadir}/cmake/
mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d
install -m 644 ${WORKDIR}/environment.d-cmake.sh ${D}${SDKPATHNATIVE}/environment-setup.d/cmake.sh
}
FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
FILES_${PN} += "${datadir}/cmake-${CMAKE_MAJOR_VERSION}"
FILES_${PN}-doc += "${docdir}/cmake-${CMAKE_MAJOR_VERSION}"
BBCLASSEXTEND = "nativesdk"
Tracing the root of the problem, I have seen that the cmake/ directory that should be created is created in:
/home/<user>/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cmake/3.10.2-r0/image/opt/poky/2.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/cmake/
However, this cmake directory is not valid in /opt/poky/2.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/, -where it is actually needed- when I install the SDK to /opt, unfortunately.
Do I need to know anything else or do anything else regarding how to properly generate SDK?
I am really stuck here any help is much appreciated indeed.
Thanks in advance.
EDIT: I moved TOOLCHAIN_TASK statements to layer.conf and used bitbake meta-toolchain which also didn't work.
EDIT2: I used cmake version 3.6 with PREFERRED_PROVIDER_cmake = "3.6.1", which also did not work.
There seems to be a bug in the imminent Yocto Project 2.5, Sumo, release. Here, sysroots/x86_64-chargestorm-linux/usr/share/cmake/OEToolchainConfig.cmake seems to be omitted.
The temporary solution for this is to add
TOOLCHAIN_HOST_TASK += "nativesdk-cmake-dev"
And yes, using a release is always helpful, especially if your new to some project. Just remember to always use the same release branches for all your included layers. And personally, I'd not start a new project based on Morty, which was released 1.5 years ago when writing this, as it's likely to go out of official Yocto Project support rather soon.
As an aside, it seems that it is still a bug (Or would this be mis-feature at this point...?) in Sumo. Just got bit by this...workaround looks to be the same as described.
(Note: This is a release at this point in time... X-D)
Problem solved by using a release (I used "morty", and not the "master branch") for every layer and poky itself. This is apparently very important.
I need to create a .ipk package from Bitbake script. My bb file:
...
PR = "r0"
PACKAGES = "${PN}"
SRC_URI = " \
file://mypackage \
file://mypackage-startup \
"
do_install() {
install -m 0775 -d ${D}/userdata/costume
install -m 0744 ${WORKDIR}/mypackage ${D}/userdata/costume/mypackage
install -m 0644 ${WORKDIR}/mypackage-startup ${D}/userdata/costume/mypackage-startup
}
FILES_${PN} += "/userdata/costume"
FILES_${PN}-dbg += "/userdata/costume/.debug"
...
But I receive the next error:
ERROR: QA Issue with mypackage: non debug package contains .debug
directory: mypackage path
/work/.../mypackage-1.0-r0/packages-split/mypackage/userdata/costume/.debug/mypackage
FATAL: QA run found fatal errors. Please consider fixing them. ERROR:
Error in executing python function in:
/home/nickname/build/mypackage.bb ERROR:
Exception: Message:1 ERROR: Printing the
environment of the function ERROR: Function do_package_qa failed
ERROR: TaskFailed event exception, aborting ERROR: Build of
/home/nickname/build/mypackage.bb do_package failed
Line with FILES_${PN}-dbg was added after net surfing. But this fix not helped in my situation.
You set PACKAGES = "${PN}" which means the debug package is never created (the default value of PACKAGES does contain ${PN}-dbg).
Either remove the PACKAGES line (if you didn't have a good reason for it) or use
PACKAGES = "${PN}-dbg ${PN}"
I am writing an custom recipe for the Bitbake for an Makefile based project. We are able to create the RPMs with all the files place in the package but we are not able to find a way for pre and post install action.
As the application runs as service we want to stop it in pre-install step and then start it in post-install step.
But I am not able to find the same so any thoughts to achieve it.
Below is the sample recipe we written for it.
DESCRIPTION = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"
SRC_URI = "file://helloworld.c"
DEPENDS = "boost"
S = "${WORKDIR}"
do_compile() {
${CC} helloworld.c -o helloworld
}
PACKAGES = "helloworld"
do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
install -d ${D}${sysconfig}/init.d
install -m 0755 ${S}/service ${D}${sysconfig}/init.d
}
I do see INITSCRIPT_PACKAGES and INITSCRIPT_PARAMS but their description doesn't talk about being pre and post action.
So any thoughts for putting %pre and %post (in terms of RPM spec) for this purpose.
You can add post install scripts in your .bb:
pkg_postinst_PACKAGENAME() {
#!/bin/sh -e
# Commands to carry out
}
Reference: Section 5.3.16 http://www.yoctoproject.org/docs/1.7.1/mega-manual/mega-manual.html
According to the documentation the examples only runs during image creation time. There is also another function that will only run on the first boot (and never after it). It uses the meta/recipes-devtools/run-postinsts recipe to accomplish this.
I ran into the same issue. See this post for how I did the post install script. Hopefully you can glean from that answer enough to modify it for your script.