Where do I specify
BB_STRICT_CHECKSUM = "0"
in Yocto to disable checksum check of source code?
I get:
ERROR: No checksum specified for /PATH/TO/ti-linux-kernel.git, please add at least one to the recipe:
SRC_URI[md5sum] = "e8e287fd725bea8b4220ebe9094cda86"
SRC_URI[sha256sum] = "4a4f522b05e6c1fcd1872f2fc7c82061dfdc4a19c5f866858005daa198f89bbb"
Regarding this page BB_STRICT_CHECKSUM is a variable which can be used in .bb files. So, you can simply add the following line to the corresponding .bb file, which your SRC_URI has been set in it, to avoid the checksum checking error:
BB_STRICT_CHECKSUM = "0"
By adding this line the checksum check error (saying: No checksum specified for blah/blah/blah, please add at least one to the recipe OR the other error saying: Missing SRC_URI checksum) won't break the compile process anymore and just a warning will be thrown.
Hope it helps
I don't see a variable named BB_STRICT_CHECKSUM in the Yocto documentation.
As far as I can tell, you shouldn't need to specify the SRC_URI[...] checksums for a git repository. In your bitbake recipe, does /PATH/TO/ti-linux-kernel.git have a git:// at the front of it? Bitbake uses that to determine the type of SCM tool to use. If you want to access a git repo via http you would specify
SRC_URI = "git://server.com/PATH/TO/ti-linux-kernel.git;protocol=http"
Maddeningly, this is only hinted at in documentation for SRC_URI.
The SRC_URI[md5sum] and SRC_URI[sha256sum] are instead intended for ensuring downloaded tarballs are the same as when you write the recipe. If you were adding a tarball (say, http://server.com/path/to/some-project.tar.gz), the recommended way is to
... comment the statements out and then attempt to build the software. The build will produce an error for each missing checksum and as part of the error message provide the correct checksum string. Once you have the correct checksums, simply copy them into your recipe for a subsequent build.
You can see in your error message that in this case they have indeed been provided.
If your cloning the repo with https://some_path you will need
SRC_URI[md5sum] = "e8e287fd725bea8b4220ebe9094cda86"
SRC_URI[sha256sum] = " 4a4f522b05e6c1fcd1872f2fc7c82061dfdc4a19c5f866858005daa198f89bbb"
while you clone the repo with git://some_path you will need
md5sum of any other file like
LIC_FILES_CHKSUM = "file://LICENSE;md5=a77c327d4d1da3707d42dde9725d4769"
Related
rust-gpu says:
Copy the rust-toolchain file to your project. (You must use the same version of Rust as rust-gpu.)
So I copied that file into my root getting rust-toolchain with contents:
# If you see this, run `rustup self update` to get rustup 1.23 or newer.
# NOTE: above comment is for older `rustup` (before TOML support was added),
# which will treat the first line as the toolchain name, and therefore show it
# to the user in the error, instead of "error: invalid channel name '[toolchain]'".
[toolchain]
channel = "nightly-2022-10-29"
components = ["rust-src", "rustc-dev", "llvm-tools-preview"]
# commit_hash = 9565dfeb4e6225177bbe78f18cd48a7982f34401
# Whenever changing the nightly channel, update the commit hash above, and make
# sure to change REQUIRED_TOOLCHAIN in crates/rustc_codegen_spirv/src/build.rs also.
Then I tried building by doing cargo-run, getting:
error: failed to run custom build command for `rustc_codegen_spirv v0.4.0-alpha.17 (https://github.com/EmbarkStudios/rust-gpu#fabcbd9c)`
Caused by:
process didn't exit successfully: `/home/makogan/rust_never_engine/target/debug/build/rustc_codegen_spirv-b4185236522e0515/build-script-build` (exit status: 1)
--- stdout
cargo:rerun-if-env-changed=RUSTGPU_SKIP_TOOLCHAIN_CHECK
--- stderr
error: wrong toolchain detected (found commit hash `e631891f7ad40eac3ef58ec3c2b57ecd81e40615`, expected `9565dfeb4e6225177bbe78f18cd48a7982f34401`).
Make sure your `rust_toolchain` file contains the following:
-------------
[toolchain]
channel = "nightly-2022-10-29"
components = ["rust-src", "rustc-dev", "llvm-tools-preview"]
I am confused, the toolchain file says the same thing as the error message, what did I do wrong?
You're running a different version of nightly than the crate requires.
To check the version of cargo try to run cargo --version from within the project directory. If it shows anything else than the version you specified in the rust-toolchain file then you can try and check out the list below for possible fixes.
Make sure that:
The cargo you're using is managed by rustup if it is cargo +stable --version should show a version number and not an error.
The rust-toolchain is in the same directory as Cargo.toml if it's not copy or move it there.
There is no override on the crates directory. You can list them with rustup override list if the crate where the error appears is listed you can unset it with rustup override unset from within the crate root.
In this specific case 3. was the culprit.
I fire up the Buildroot by make. Compilation progress was successful.
In the installation progress, it tried to copy /output/build/uboot/SPL but that folder does not exist. Instead, /output/build/uboot/spl exists.
I changed the spl folder name to SPL
Run the make again but I got .stamp_images_installed failed error. Check the end of the post for full error log.
To solve the problem, I want to build the target again so I removed output/target folder and all the .stamp_images_installed files under output/build but still I got .stamp_images_installed failed error.
Why Buildroot still gives me this error ? What am I doing wrong ?
My full error log is as the following;
>>> uboot e1cbe8c74e87036e649b0e34656aebabb3aa00c7 Installing to target
>>> uboot e1cbe8c74e87036e649b0e34656aebabb3aa00c7 Installing to images directory
cp -dpf /home/mei/buildroot/output/build/uboot-e1cbe8c74e87036e649b0e34656aebabb3aa00c7/u-boot.bin /home/mei/buildroot/output/images/
cp -dpf /home/mei/buildroot/output/build/uboot-e1cbe8c74e87036e649b0e34656aebabb3aa00c7/u-boot.img /home/mei/buildroot/output/images/
cp -dpf /home/mei/buildroot/output/build/uboot-e1cbe8c74e87036e649b0e34656aebabb3aa00c7/SPL /home/mei/buildroot/output/images/
cp: -r not specified; omitting directory '/home/mei/buildroot/output/build/uboot-e1cbe8c74e87036e649b0e34656aebabb3aa00c7/SPL'
package/pkg-generic.mk:320: recipe for target '/home/mei/buildroot/output/build/uboot-e1cbe8c74e87036e649b0e34656aebabb3aa00c7/.stamp_images_installed' failed
make[1]: *** [/home/mei/buildroot/output/build/uboot-e1cbe8c74e87036e649b0e34656aebabb3aa00c7/.stamp_images_installed] Error 1
Makefile:84: recipe for target '_all' failed
make: *** [_all] Error 2
Thanks!
There is a folder called spl (in lowercase), but we're looking for a file called SPL (in uppercase). When you build a first stage bootloader, it may have various names, depending on the platform. Usually the name is u-boot-spl.bin, and it resides inside the spl directory. Some platforms, however, use a different name for this file (for historical reasons). For iMX6, the file name is SPL and it resides directly in the U-Boot directory.
However, in your case, apparently the SPL file doesn't get built. Probably this is because you are using a U-Boot configuration that doesn't build it under that name. If you are actually building for iMX6, this indicates that there is something wrong with your U-Boot configuration. If you're building for some other SoC, it's Buildroot's BR2_TARGET_UBOOT_SPL_NAME option that is incorrectly set.
I'm trying to add an br2-external package to a Buildroot build for a sama5d4_xplained board. I'm testing it using the utils/test-pkg utility and with every toolchain it fails on BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y, according to the missing.config file. It's an entry in the sama5d4_xplained_defconfig, which is used in the build.
I attempted to find what does the option mean in the manual and by googling, but any information is nowhere to be found. It doesn't seem to be related to the version of kernel headers installed on my machine, since my headers are 4.15.
The exact command used is:
./utils/test-pkg -c ../../config/sama5d4_xplained_defconfig -p {package}
The sama5d4_xplained_defconfig has the problematic entry:
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
logfile content:
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
Using support/config-fragments/autobuild/br-arm-full-static.config as base
Merging support/config-fragments/minimal.config
Merging ../../config/sama5d4_xplained_defconfig
GEN /home/bartlomiej/br-test-pkg/br-arm-full-static/Makefile
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
Using support/config-fragments/autobuild/br-arm-full-static.config as base
Merging support/config-fragments/minimal.config
Merging ../../config/sama5d4_xplained_defconfig
GEN /home/bartlomiej/br-test-pkg/br-arm-full-static/Makefile
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
What does this entry mean, and what do I do to fix the build problems?
You have to make a configuration file that enables just your package. With recent Buildroot, you can also use test-pkg -p <pkg> without -c option.
test-pkg will do a build-test of one or more packages with a collection of different toolchains (by default, a subset of the toolchains used for the autobuilders). The configuration file you supply with -c is supposed to select the package(s) that you want to test. Any toolchain that does not satisfy the dependencies of those packages will be skipped.
The board defconfigs (like sama5d4_xplained_defconfig) build a toolchain as part of their configuration. This toolchain always differs from the toolchains used in the autobuilders. Therefore, if you supply one of the defconfigs as the -c option, all toolchains will always be skipped.
However, if you are only interested in the sama5d4 Xplained board, there is no real need to use test-pkg to test your package with all toolchains. Just enable the package to a custom configuration.
I'm using CMake for my recent project and I want to confirm that the right path is set
set(_protobuf_include_path -I . -I ${_gRPC_PROTOBUF_WELLKNOWN_INCLUDE_DIR})
I used message to check the value of _gRPC_PROTOBUF_WELLKNOWN_INCLUDE_DIR but not printing anything in terminal
message( STATUS ${_gRPC_PROTOBUF_WELLKNOWN_INCLUDE_DIR} ) # no output for this
My intention is to build Grpc1.14.1, bit it is having dependency with protobuf, so I downloaded protobuf 3.6.01 and both grpc and protobuf kept under same directory (home/user/src).
While building I got this error
google/protobuf/stubs/common.h: No such file or directory
#include <google/protobuf/stubs/common.h>
So I opened protobuff.cmake in directory gRPC/cmake and changed the protobuf root path
if(NOT PROTOBUF_ROOT_DIR)
#set(PROTOBUF_ROOT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/third_party/protobuf)
set(PROTOBUF_ROOT_DIR ../../ThirdParty/protobuf)
[...]
After doing this, I'm still getting the same issue.
First, something a bit irrelevant to the question, but related to modern CMake techniques and usage.
In order to set the include path, it is preferred to use the target_include_directories command, e.g.
target_include_directories(mytarget
PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}
PUBLIC ${_gRPC_PROTOBUF_WELLKNOWN_INCLUDE_DIR}
)
Now, for the actual question, it would help if you could show the actual setting of ${_gRPC_PROTOBUF_WELLKNOWN_INCLUDE_DIR}, (is it through the command line via `-D) options?)but you could print it like this:
message(STATUS "include dir: ${_gRPC_PROTOBUF_WELLKNOWN_INCLUDE_DIR}")
I'm suspecting spurious whitespace or something along those lines in the actual variable contents.
How can i write own package for recipe in arago project build? I know little bit that it can be bitbake files. But how can i write, no idea. I searched on internet, but failed to find any good source to start. can someone provide me link or example to start?
Regards
Linux Learner.
Create own recipe with Yocto using Bitbake:
Use Yocto Project for Embedded systems. It's documentation and support is awesome. You can get started Yocto Project.
Build your own recipe(for the first time build takes quiet good amount of time)
Getting Yocto Project:
Follow step-by-step procedure given Gumstix-YoctoProject-Repo till bitbake gumstix-console-image
Now you got yocto project on your machine. Start writing your own recipes. I will show you how to create a hello world recipe.
1) goto /yocto/poky/<create a folder as meta-robot>
2) goto /yocto/poky/meta-robot/<create a folder as /recipes-robot> and <another folder /conf>
3) goto /yocto/poky/meta-robot/recipes-robot/<create another folder /hello>
4) goto /yocto/poky/meta-robot/recipes-robot/hello/<create a file as 'hello_2.7.bb'>
5) Paste this in your hello_2.7.bb
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI[md5sum] = "fc01b05c7f943d3c42124942a2a9bb3a"
SRC_URI[sha256sum] = "fd593b5bcf6d1bb6d7d1bb7eefdccdc0010cf2c4985ccb445ef490f768b927c0"
SRC_URI = "ftp://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz"
inherit autotools gettext
6) goto /yocto/poky/meta-robot/conf/<create a file as layer.conf>
7) paste this in your layer.conf file
# We have a conf directory, append to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "meta-robot"
BBFILE_PATTERN_meta-robot := "^${LAYERDIR}/"
BBFILE_PRIORITY_meta-robot = "7"
8) Open /yocto/build/conf/bblayers.conf file
9) Add your recipe folder path in bblayers file
ex: /home/xyz/yocto/poky/meta-robot \
10) open /yocto/poky/meta-gumstix-extras/recipes-images/gumstix/gumstix-console-image.bb file and under TOOLS_INSTALL add your recipe name i.e.hello \
11) Open your terminal type $ cd /yocto
12) $ source ./poky/oe-init-build-env
13) type bitbake gumstix-console-image
That's it. Your image with your own package will be ready in some time.
You can find your image in /yocto/build/tmp/deploy/images/
All the Best.
Arago is a distribution based on OpenEmbedded project and Bitbake build tool. Logically, you should start with Bitbake manual and OpenEmbedded manual. These are slightly outdated, but still relevant in most part. After that, there is a good, simple tutorial found here.
Also I find #oe channel on FreeNode to be very useful.
EDIT: There is a newer manual for Yocto/Poky that also covers Bitbake and OpenEmbedded.
I think what the other guy has answered to create a new recipe is actually creating a layer.
You can do it by
$ . ./setup-environment build-dir
$ yocto-layer create custom #here you may change the name to your custom layer name.
If you do this, it will automatically ask you to create an example recipe for you.
But I guess that's not the question.
You need to change or customize .bb file.
It has few fields namely
SOURCE_URI=" "
This is the one where you are getting the source tar file for the package.
Then do_compile = " " and do_install = " ". This may not be easy for a newbee like you and me.
You can create a recipe using create-recipe or recipetool.
Check the below link for their usage
http://ashversity.blogspot.in/2016/02/creating-new-yocto-recipe.html