Iam Running my project in the QEMU Setup. Changed the bitbake recipe for a component with native to support "make analyze" and "make check".
Issued Below commands:
bitbake -c clean <component_name-native>
bitbake -c compile <component_name-native>
bitbake -c analyze <component_name-native>
bitbake -c check <component_name-native>
Running the commands in the location
rvea#rtscl076[/data/users/project/poky/build]
No Errors from the above commands.
My Question is where to find the analyze output logs stored for the component. so that i can correct the errors found for the particular component.
Thanks in advance!!
Firstly, are you sure that those commands were really executed?
Try the -f (force) option to ensure that:
bitbake -c <task> -f <target>
Secondly, check out the reference manual which provides information about where you can find log files for each task and some tips on debugging: Yocto Project Reference Manual - Debugging Build Failures
Related
Some years ago on Ubuntu 16.0.4 I've used this library: git clone https://github.com/Beckhoff/ADS and using only the make command I got build, compile and finally on the main directory I found a file called AdsLib-Linux.a and maybe nothing more than this.
Now I'm on Ubuntu 20.04 I need this library once again but this times make dosn't produce the same output and looking forth to the ReadMe instructions I finally used that instead of make:
meson build
ninja -C build
That now create a new directory build but no .a file as before on the root directory. Instead a new file in the build directory libADSLib.a is there. The same thing happens using right the make command.
Maybe the author changed over the years something on the config files or the behavior of the tools have changed, but I cannot get the former file anymore and I need it for other referencing code that now is not executing anymore.
Looking to the MakeFile I found that in the example folder, differently from the one on the parent directory, the MakeFile has something like that:
$(warning ATTENTION make is deprecated and superseeded by meson)
...
${PROGRAM}: LIB_NAME = ../AdsLib-${OS_NAME}.a
...
But all i've tried reading the guides on meson and ninja about setup, configure, build, and so on, did not produce anymore that file.
I've tried also to first build and then copy all files form the example folder to the parent directory and then build again, but again no .a file there.
How's the right way to configure the build process corectly so that this -Linux.a file is created. Or if not possibile anymore, what does it now produce I can use instead of what produced before?
Meson is a build system generator, similar to CMake or somewhat like ./configure, you need to run meson, then run ninja to actually build something.
You need to run both meson and ninja:
meson setup builddir
ninja -C builddir
Once you do that successfully, there will be a libAdsLib.a inside the builddir directory.
Let me correct a bit #dcbaker, according to their README you should setup build as build directory:
# configure meson to build the library into "build" dir
meson build
# let ninja build the library
ninja -C build
Of course, in general, it shouldn't be specific, but their example code is written in a weird way so this path is hard-coded. So, to use the example:
# configure meson to build example into "build" dir
meson example/build example
# let ninja build the example
ninja -C example/build
# and run the example
./example/build/example
About the library: it's now libAdsLib.a and produced in build directory. The name is set here and it's now in linux naming style, the old one - not. So, you have options:
Update your configuration/build files (Makefile?) where you use it
Copy or make symbolic link, e.g.
$ ln -s <>/build/libAdsLib.a <target_path>/AdsLib-Linux.a
Above it's very dependent on your development environment, do you have installation or setup scripts for it? do you permissions to modify/configure parameters for target application? do you need to support both old and new names? - many questions not related to original question about meson.
I encountered the problem that I wanted to have a debug, then I wanted to build a debug version of tensorflow, using the following command:
bazel build --compilation_mode=dbg -s //tensorflow/tools/pip_package:build_pip_package
but it will trigger the longtime link in protobuf for almost oneday, and still not finished.
and my intension is to build some other package which is used by tensorflow with debug mode, could I configure the bazel build file to get some debug package separately?
To understand the issue better, try running the neverending action manually:
start the debug build, wait for it to get stuck in the protobuf linking action
interrupt the build (Ctrl+C)
run the build again with the -s flag, so Bazel shows the command line it executes (you could've ran step 1. with the -s flag, but then there's a lot more output and it's harder to find the right information)
interrupt the build again
cd into the directory shown in the by command and set environment variables
try running the command that failed (you may need to change the output paths because they are sometimes not user-writable) and see if it still never finishes
What you just did is running the same command Bazel was running and getting stuck on. If the command is stuck in this manual mode too, then the error might be with the linker (I doubt this is the case though). But if it succeeds, then the problem is with Bazel.
Update: This question is already SOLVED. I'm re-editing the question to update to the fixed state.
I'm trying to write a recipe that uses dep tool to resolve dependencies of a go related project before building it. I'm using the 'poky' layer of the 'rocko' Yocto project branch. That branch provides recipes to build the go compiler and the dep dependencies tool.
My initial recipe fetches source code from a bitbucket repository:
GO_IMPORT = "bitbucket.org/path/to/my_project"
SRC_URI = "git://${GO_IMPORT}/protocol=http;user=${GIT_USER}:${GIT_PASS};destsuffix=${PN}-${PV}/src/${GO_IMPORT}"
Then I add this:
inherit go
DEPENDS += "go-dep"
And after I add this function:
do_compile_prepend() {
dep init
dep ensure
}
Yocto complains with this error:
run.do_compile.8543: line 118: dep: command not found
After reading some of your answers below, I add suggested patch in your answers at the end of my poky/meta/recipes-devtools/go/go-dep_0.3.0.bb recipe file - thanks a lot!! :-)
BBCLASSEXTEND = "native nativesdk"
After I execute some bitbake commands:
$ bitbake -c cleanall go-dep-native
$ bitbake go-dep-native
Bitbake process ends ok, displaying no errors nor warnings. The native go-dep tool has been built into tmp/work/x86_64-linux/go-dep-native directory and is properly installed into tmp/sysroots-components/x86_64/go-dep-native/usr/bin.
I modify the do_compile_prepend() function as shown below:
do_compile_prepend() {
rm -f ${WORKDIR}/build/src/${GO_IMPORT}/Gopkg.toml
rm -f ${WORKDIR}/build/src/${GO_IMPORT}/Gopkg.lock
cd ${WORKDIR}/build/src/${GO_IMPORT}
dep init
dep ensure
}
I modify DEPENDS in my recipe like this:
DEPENDS = "go-native go-dep-native"
Note the go-dep has been removed (I don't need dep tool on the target device, just to resolve dependencies on the native platform).
After that, I execute this command:
$ bitbake <foo>
The do_compile stage works fine, but some errors appear when doing the do_package stage:
ERROR: <foo>-1.0-r0 do_package: QA Issue: File '/usr/bin/dep' from <foo> was already stripped, this will prevent future debugging! [already-stripped]
ERROR: <foo>-1.0-r0 do_package: Fatal QA errors found, failing task.
ERROR: <foo>-1.0-r0 do_package: Function failed: do_package
These errors are fixed appending this at the end of my recipe:
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INHIBIT_PACKAGE_STRIP = "1"
RDEPENDS_${PN}-staticdev += "bash"
RDEPENDS_${PN}-dev += "bash"
I don't know if this is the best way to solve my issue, but at least now it works fine. Any advice to improve this recipe is wellcome. Thank you in advance! :-)
The DEPENDS += "go-dep" means that your target recipe can include headers or link libs provided by go-dep, but you can't run the dep command, if you need run dep command, you need depend on go-dep-native:
DEPENDS += "go-dep-native"
But yocto doesn't provide go-dep-native currently, so you have to add:
BBCLASSEXTEND = "native"
to meta/recipes-devtools/go/go-dep_XXX.bb.
Then you can run dep command in do_compile_prepend()
I just sent the patch[1] to enable the native and nativesdk support for the recipe.
https://patchwork.openembedded.org/patch/147390/
Assuming you're using the same recipe as the one here, you should be able to refer to the ${GO_INSTALL} variable in your do_compile_prepend build step. If not, try running -c devshell with your bitbake command, like:
bitbake <package name> -c devshell
and look for the path of the dep tool.
I'm using a embedded linux on a SOM module, based on IMX6.
I would like to patch my kernel,it works fine, it has been patched, but i would like to add some features.
I apply the old patches on the sources, and add my code, and create a new patch.
In yocto I add my patch to the recipe and bitbake it, I start the board with the new loaded kernel, and it seems it does not have my modification!
For bitbake my new kernel, I type :
bitbake -c clean linux-toradex-fsl
bitbake linux-toradex-fsl
It compiles without any errors, I copy my uImage in my tftp folder, but my features do not seems to be executed.
So I try to create a simple patch, with
printk(KERN_WARNING"This is a test\n");
I place it after another warning, called and displayed.
And it does not work either.
I check with -c devshell and my modification are applied in yocto, the patch works here.
I also check the uImage file, it has the same size, with or without my patches.
Do you have some ideas for this issue?
Regards,
Pierre-Olivier
Solution
I found the solution after some tries, I just need to run
bitbake -c cleansstate linux-toradex-fsl
bitbake my-image
And the image is bitbaked with the patched kernel.
Bitbake is funny about -clean. It tries to keep a state directory, so -clean just runs the normal "clean" in the makefile, but the makefile can be short-circuited by the shared state, which can include zipped up prebuilt binaries from a previous build. Try this:
bitbake -c cleansstate linux-toradex-fsl
bitbake linux-toradex-fsl
note the extra 's' in cleansstate (clean shared state).
I am working on a kernel module for a project using Yocto Linux (version 1.3). I want to use the kernel headers and the compiler and libraries from my Yocto project, but develop the kernel module without needing to run bitbake every time. My initial solution to this was to execute the devshell task and extract the environment variables using something like this:
bitbake mykernel -c devshell
Then in the new xterm window bitbake opened for me:
env | sed 's/\=\(.*\)/\="\1"/' > buildenv #put quotes around r-values in env listing
^D #(I leave the devshell)
Then copy this to my development directory and source it before running make with all of its options
KERNEL_PATH=/mypathto/build/tmp/sysroots/socfpga_cyclone5/usr/src/kernel
source ./buildenv && make -C $KERNEL_PATH V=1 M=`pwd` \
ARCH=arm CROSS-COMPILE=arm-linux-gnueabihf- \
KERNEL_VERSION=3.13.0-00298-g3c7cbb9 \
CC="arm-linux-gnueabihf-gcc -mno-thumb-interwork -marm" \
LD=arm-linux-gnueabihf-ld AR=arm-linux-gnueabihf-ar
Now to my questions:
Am I going about this completely wrong? What is the recommended way to cross-develop kernel modules? I am doing it this way because I don't want to open a bitbake devshell and do my code development in there every time.
This sort of works (I can compile working modules) but the make script gives me an error message saying that the kernel configuration is invalid. I have also tried this with KERNEL_PATH set to the the kernel package git directory (build/tmp/work///git (which contains what appears to be a valid .config file) and I get a similar error.
How can I extract the env without needing to open a devshell? I would like to write a script that extracts it so my coworkers don't have to do it manually. The devshell command opens a completely separate Xterm window, which rather dampens its scriptability...
the sdk installer is what you are looking for:
bitbake your-image -c populate_sdk
then, from your build directory go to tmp/deploy/sdk
and execute the generated shell script.
this script will allow you to generate and install an sdk.
Not only the sdk will allow you to (cross) compile your kernel by providing the needed environment variables and tools, but it will also provide a sysroot + a standalone toolchain to help you easily (and by easily I mean really easily) crosscompile applications with the autotools (as long as you provide Makefile.am and configure.ac)
just source the environment-setup-* file, got to your kernel directory and compile.
Or, for application developpment based on the autotools,
go to the folder containing your project (sources + Makefile.am and configure.ac)
and do:
libtoolize --automake
aclocal
autoconf
automake -a
now your project is ready for compilation:
./configure $CONFIGURE_FLAGS
make
make install DESTDIR=path/to/destination/dir
If you're after a quick hack, instead of Ayman's more complete solution, the scripts run to complete each build stage are available in the directory:
./build/tmp/work/{target_platform}/{package}/{version}/temp/run.do_{build_stage}
These scripts can be run standalone from the ./temp/ directory, and contain all of the environment variables required.