I am working on yocto, I have a component which I am compiling manually using cmake command. I need to select some options using cmake while compiling. cmake -Dex=on ..., which enables "ex"
Now I am trying to do the same in the yocto, for compilation I used inherit cmake in bb file, but I am not to pass this option -Dex=on
My bb file looks like this
SECTION = "devel"
LICENSE = "CLOSED" SRC_URI = "file://*"
SRC_URI = "gitsm://****.git;protocol=ssh"
SRCREV="${AUTOREV}"
S = "${WORKDIR}/git"
inherit cmake
How can pass cmake options in the bitbake file?
You define the extra symbol by setting
EXTRA_OECMAKE += "-Dex=on"
when you have inherit cmake in your recipe.
The variable is used by the cmake.bbclass when cmake is called.
Related
What changes should make to enable dlt-system.
In build folder dlt-system application is not generating.
Manually by using command: cmake -D with dlt-system=ON it will generate but I need to generate while building please look at recipie image
Your recipe supports dlt-system via PACKAGECONFIG.
In order to activate that flags in the compilation process, you just need to add dlt-system to PACKAGECONFIG in .bb or .bbappend file to the recipe:
PACKAGECONFIG_append = " dlt-system"
If you want to add it from local.conf:
PACKAGECONFIG_pn-name_append = " dlt-system"
Just change name with your recipe name.
This will add -DWITH_DLT_SYSTEM=ON to EXTRA_OECMAKE which is used in do_configure of the cmake class.
I have an external application that converted to an exe using pyinstaller. This needs to be added in yocto framework. But the application has a dependency on pylint & pyinstaller. pylint is already part of yocto framework. I used meson.build file in my application and have a recipe file in yocto that will source the entire application from git repo and builds using instructions in meson.build. In my application meson build file uses find_program() to find pylint program installation. It works currently on my laptop, but when I build my application recipe in yocto environment, it is unable to find pylint. Even though I added "python3-pylint" in IMAGE_INSTALL_append.
| Program python3 found: YES (.../usr/bin/python3-native/python3)
| Program python3 (pylint) found: NO
|
| ../git/src/meson.build:10:0: ERROR: python3 is missing modules: pylint
pyinst = find_program('pylint') // as per meson this is probably searching in /usr/local/bin. But this is not the case in yocto. How can I modify find_program() call to find this in the right location in yocto framework. Or is there any method to handle this?
meson.build under source file folder:
# get & run pylint to check for errors
prog = import('python').find_installation('python3', modules: ['pylint'])
if not prog.found()
message('pylint not found')
else
message(prog.path())
cmd = find_program('pylint', prog.path())
message('Running pylint on src files')
foreach each : src_files
run_command(cmd, '--confidence=HIGH', each)
endforeach
endif
project's meson.build
project('proj_name',
['cpp'],
version : '0.1',
license : 'MIT',
default_options: [
'cpp_std=c++11']
)
project_pretty_name = 'proj_name'
project_url = '<git repo of project>'
python = import('python')
python3 = python.find_installation('python3', required: false)
subdir('src')
subdir('tools') # cpp tools
subdir('build')
yocto recipe file:
inherit meson pkgconfig python3native
DEPENDS += "${PYTHON_PN}-distro-native"
DEPENDS += "zlib"
RDEPENDS:${PN} += "${PYTHON_PN}-requests \
${PYTHON_PN}-pylint"
SRC_URI += "<git branch>"
SRCREV = "<src-rev>"
S = "${WORKDIR}/git"
FILES:${PN}:append = " ${bindir}/mesonexe"
Your Meson build requires pylint to be available during compilation, therefore you need to add:
DEPENDS += "${PYTHON_PN}-pylint-native"
and then you will need to ensure the pylint recipe is available in one of your configured Yocto layers. It's in meta-openembedded/meta-python.
Finally, the python3-pylint recipe and one of its dependencies (python3-astroid) do not have native support enabled, so you'll need to create the followin .bbappends as well:
# python3-pylint_%.bbappend
BBCLASSEXTEND += "native"
# python3-astroid_%.bbappend
BBCLASSEXTEND += "native"
You should then see the following line in the Meson output:
Program pylint found: YES (.../recipe-sysroot-native/usr/bin/pylint)
As a suggestion - if this recipe is building your own source code, I'd suggest linting the code as it is pushed into the repository (via a CI job), rather than at compile-time. This will reduce the dependencies required to build your project.
Of course, there would still be an optional Meson target for developers to lint their code before they push new code. Perhaps something that is enabled for non-release builds by default.
This follows on from
How do I strip and objcopy a built .so file in the Yocto bitbake compile step?
This leads back to considerable background information.
As mentioned in the previous question, I am seeking to build OCA, which I have
as a non-Yocto makefile-based project, in Yocto. The project, which builds
fine outside of Yocto, and even in Yocto, is quite complex. The issue is that it
is not cross-compiling for my target, which is aarch64 armv8-a. It is building
successfully, but for my host machine, which is x86-64. Then Yocto sensibly
refuses to package it, saying "Unable to recognise the format of the input
file".
I changed the compile flags in my makefile to -march=armv8-a, but got the error
"cc1plus: error: bad value ('armv8-a') for '-march=' switch" which seems to
mean that I can't use the host's installed gcc for cross-compiling, but rather a
cross-compiler is needed. I previously custom-added two additional layers, a
sample helloworld and mDNS (see previous questions for lots of background), and
they all cross-compiled fine, so I know that Yocto is basically set up to do it.
What is the method to get the cross-compilation to happen? Do I need to do a lot
of pervasive changes to my project's makefile system? It may not ever have been
designed with Yocto in mind.
I am looking into this: "cross-compile library recipe in yocto":
cross-compile library recipe in yocto
which seems to have some relevant information. Edit: it was only standard stuff that I had seen before; nothing about how cross-compilation gets invoked instead of the host machine's gcc.
Edit: My updated recipe, with the FILES_${PN} added and make changed to
oe_runmake.
DESCRIPTION = "OCA"
PRIORITY = "optional"
SECTION = "protocols"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://oca-1.2.7"
S = "${WORKDIR}/oca-1.2.7/Src"
# Need to override S because BitBake expects the source to be in a dir called
# oca-1.2.7 in the work dir, but it's actually additionally under Src/.
# Need a do_compile, since OCA has a makefile with a non-standard name,
# makefileOCA. Also needs non-standard flags, -f and linuxRelease.
do_compile() {
export CAP_HOME="${WORKDIR}/oca-1.2.7"
oe_runmake -f makefileOCA linuxRelease
}
do_install() {
install -d ${D}${libdir}
cp ../Obj/linuxApp/Release/OcaProtoController.so ${D}${libdir}/OcaProtoController.so
chmod 0755 ${D}${libdir}/OcaProtoController.so
}
FILES_${PN} += "${libdir}/OcaProtoController.so"
Edit: I found some info:
https://www.yoctoproject.org/docs/1.8.1/adt-manual/adt-manual.html
https://www.yoctoproject.org/docs/1.8.1/adt-manual/adt-manual.html#setting-up-the-cross-development-environment
I commented-out the setting of CC and LD in makeOCA.inc.
I did the cleaning actions of deleting the tmp folder from my build-wayland
build dir, and did "bitbake -c cleansstate oca". Then I did "time bitbake oca".
Now it looks like it is using the cross compiler.
The first error I got now is:
~/Yocto/imx-yocto-bsp/build-wayland/tmp/work/aarch64-poky-linux/oca/1.2.7-r0/oca-1.2.7/Obj/linuxApp/Release/OcaAgentProxies.a
aarch64-poky-linux-ld: cannot find crus: No such file or directory
So this is the next question: Can you tell me what "crus" means in "LDFLAGS = crus $#"?
I am trying to install a set of CMake utilty functions under /usr/share/cmake-3.4/Modules/MYMODULES/useful.cmake within a Yocto build.
Here is my current (sanitized) recipe (call it my-useful-modules.bb)
SECTION = "devel"
LICENSE = "CLOSED"
inherit cmake
EXTERNALSRC := "path/to/source/code"
do_compile() {
:
}
FILES_${PN} += "${datadir}/cmake-3.4/Modules/MYMODULES/*"
BBCLASSEXTEND = "nativesdk"
The configure and install tasks work fine, and if I look under image in tmp/work/..., I see the full tree (including all my host directories as expected).
But I keep getting the following error
ERROR: nativesdk-my-useful-modules-1.0-r0 do_package: QA Issue:
nativesdk-my-useful-modules: Files/directories were installed but not
shipped in any package:
Followed by a long list of files which basically includes everything under image.
These modules need to be available both in the native sysroot during the build, and in the standard SDK built with populate_sdk.
Which package should I be specifying with FILES_${PN} to get them packaged?
I'd also appreciate knowing how to either avoid specifying the cmake version in the FILES statement, or get it from the build system.
Updating FILES_${PN} will resolve your error and also there is no need to provide cmake version in this case.
FILES_${PN} += "${datadir}/*"
I have been using Yocto to create Linux builds for an ARM board.
I had been cross compiling add on applications manually. Now we are in a place where we would like a nice integrated build so I started adding custom recipes to yocto.
I have been struggling with the ARM build (a x86 build with the same code seems fine).
Even a basic 'hello world' pretty much cut and paste from the development manual does not work (http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe)
Here is the recipe:
SUMMARY = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
RPROVIDES_${PN} = "helloworld"
FILES_${PN} += "${bindir}"
SRC_URI = "file://helloworld.c"
S = "${WORKDIR}"
do_compile() {
${CC} helloworld.c -o helloworld ${LDFLAGS}
}
do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
}
Here is the error:
ERROR: helloworld not found in the base feeds (smarc_samx6i cortexa9t2hf-vfp-neon-mx6qdl cortexa9hf-vfp-neon-mx6qdl cortexa9t2hf-vfp-neon cortexa9t2hf-vfp cortexa9hf-vfp-neon cortexa9hf-vfp armv7at2hf-vfp-neon armv7ahf-vfp-neon armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp armv5ehf-vfp armv5thf-vfp armv5hf-vfp noarch any all).
ERROR: Function failed: do_rootfs
Any suggestions as to what would be causing this error?
The package does build properly; the problem seems to be isolated to finding it for the rootfs.
Thanks!
EDIT:
I have a solution that seems to work, although it is not ideal long term.
Changing the package name under IMAGE_INSTALL from helloworld to helloworld-0.0.1 resolves the issue. Obviously I would rather not hard code the version of each package in the top level recipe and other packages do not require this, so hopefully there is another solution.
EDIT 2:
Renaming the recipe and removing the version string also resolves the issue. Once again, this does not seem ideal long term.
OK, after some further testing I discovered this was a naming issue with the recipe.
It was named helloworld-0.0.1.bb (the same format with the other recipes I had put together driving me to try this simple test).
If anyone else encounters this simply replacing the '-' with a '_' resolves this.
1.Rename your recipe name e.g hello-0.1.bb to hello_0.1.bb
2.Add below line at last only:
FILES_${PN} = "${bindir}/*"
Abvoe line helps you copy your binary to rootfs.