When I build the core-image-minimal of poky-tiny, bash is not included.
When I add the package openssh-sshd in IMAGE_INSTALL, then bash is added in the image. Why?
(bash is not needed in my case and is cumbersome)
I looked at the result of bitbake -e but did not find the reason.
What other means do I have other than looking at bitbake source code and putting some debug prints everywhere?
Actually I was wrong: bash is not included in the built image.
The files recipe-depends.dot and pn-buildlist (resulting from bitbake -g) indicate the presence of bash, but after actually building the image, bash is not in the manifest nor in the image.
I cannot explain this difference.
I am going to close or delete my question (because it is a wrong question).
Related
I've been trying to use WSL to generate html reports for the code coverage of my flutter project, but this happens when I run genhtml coverage/lcov.info -o coverage/html:
Reading data file coverage/lcov.info
Resolved relative source file path "lib\blocs\bloc1\bloc1.dart" with CWD to "/mnt/c/Users/User/flutter_project/lib\blocs\bloc1\bloc1.dart".
Found 284 entries.
Found common filename prefix "/mnt/c/Users/User/flutter_project"
Writing .css and .png files.
Generating output.
Processing file flutter_project/lib\otherDir\other_file.dart
genhtml: ERROR: cannot read /mnt/c/Users/User/flutter_project/lib\otherDir\other_file.dart
I can understand that this has possibly to do with the paths, but I'm not sure on how to fix it. Any tips?
I ran into the same problem when attempting to use lcov through WSL, and I have figured out the issue.
The lcov file generated by flutter test --coverage on Windows has back slashes \ for paths instead of forward slashes /.
Simply replacing all back slashes in your lcov.info file with forward slashes before running genhtml, should resolve the issue.
I don't know if this could be useful in that environment.
I had the same problem, and to solve it I created this script. I hope this helps you!
https://github.com/jorgesarabia/flutter_coverage
Please let me know if this solves your problem!
I tried this!!
Instead of cd'ing into coverage/ then running genhtml lcov.info -o anything
Just run the whole command from the root of project, So the new command will look something like this:-
genhtml coverage/lcov.info -o anything
P.S. I was trying to run a coverage file generated by Flutter test.
I am working on an embedded project on Zedboard. I would like (at least for now) to use Bitbake only to produce proper rootfs. I use recipe core-image-minimal, as I need only limited amount of staff there. How can I "tell" it to not compile kernel, not make u-boot, etc. and focus on rootfs only?
Here is what I've done so far:
Created my build environment
Downloaded needed layers
Modified local.conf to add needed packages to rootfs
Then after typing
bitbake core-image-minimal
I get my rootfs, and all this unnecessary staff. How can I avoid it?
I recently had the same need to only build the rootfs with yocto, skipping other things such as kernel, uboot, image creation etc. There are many legitimate reasons to do so. Anyways, this is what you have to do:
bitbake core-image-minimal -c image_cpio
in krogoth, this will populate the rootfs directory in build/tmp/work/$MACHINE/core-image-minimal/1.0-r0/ and create a rootfs.cpio file in build/tmp/deploy/images/$MACHINE/
in morty, the rootfs.cpio archives seem to be in build/tmp/work/$MACHINE/core-image-minimal/1.0-r0/deploy-core-image-minimal-image-complete/
Interesting concept. However, from what I observed, Yocto must get the defconfig in kernel and u-boot to do configuration on the image itself. Therefore, removing the process will make rootfs not bootable.
These happened for me a lot of time since I used different kernels to compile for different machines. I thought that the ARM image will be the same and will work for all machine but I was wrong.
For Debian, the image compiled need to use kernel's corresponding configuration to compile the rootfs for it to work. And Yocto is the same.
bitbake -e |grep IMAGE_FSTYPE
will give you something like:
IMAGE_FSTYPES="tar.gz cpio cpio.gz.u-boot ...."
it's a list of all the image that will be generated, to remove the undesired ones, in the local.conf file use:
IMAGE_FSTYPES_remove = " cpio cpio.gz.u-boot"
the space before the first element it's not optional.
Regards
If you don't want to build a kernel set the preferred provider of virtual/kernel to 'linux-dummy'.
I have a touch panel computer running ARM9. I have successfully built a QtEmbedded SDK image under OpenEmbedded toolchain (I am newbie in this area) for ARM9. I'd like to re-build QtEmbedded images again with few examples that it comes (not all) with due to space limitation on NAND. How can I re-compile this. I have commented out examples in examples.pro but it seems it's building images from existing packages. I am using command: bitbake -b qt4-embedded-image
Please help.
Nimesh
You need to re-run the configure step of the bitbake to rebuild the Makefiles from the .pro files. You can do this by removing the configure stamp for this package. Just rm the do_configure stamp for this package and re-run the bitbake command you did above.
I just want to develop a C app in linux with the auto(make/conf/...) stuff automatically generated. I tried generating it with ede and anjuta, but it doesn't seem to generate Makefile.am. So, I tried running automake, and it says "ltmain.sh" isn't found. Is there some easy to generate the basic build files for linux C/C++ apps. What is the standard practice? Do most people write these files themselves?
Generating a really trivial set of autotool files is pretty easy. Here's a (really basic) example. After you run these, you should get a copy of ltmain.sh in the directory, and you'll be all set to run the configure script:
$ mkdir sample
$ cd sample
$ echo 'int main( void ) { return 0; }' > foo.c
$ echo 'bin_PROGRAMS = foo' > Makefile.am
$ autoscan
$ mv configure.scan configure.ac
$ # edit configure.ac, add AM_INIT_AUTOMAKE([foreign])
$ # and LT_INIT, set project name and bug-report-address
$ autoreconf -ivf
Note that in this example, libtool really isn't necessary since
the example is just building a simple app. But you asked about
ltmain.sh, and that's a libtool thing so LT_INIT is needed to
address that portion of the question. If you want to build
a library, change bin_PROGRAMS to lib_LTLIBRARIES.
EDE can work with your Automake files in two different ways. If you write your own automake files, it will read them, and tweak them via the UI.
If you prefer, you can have EDE do the whole thing for you. First, create your first C file, then when it is on disk, do:
M-x ede-new RET Automake RET
then from the project/project options menu, add a target, like "program".
If you fill in your C file, you can then choose Project->Build->build currentproject from the menu, and it will create and setup everything needed for Automake to do it's thing, in addition to running all the misc automake commands needed.
Lastly, there is a 'run' option somewhere to run your program.
I'd consider not using autoconf and automake at all -- their complexity outweighs their benefit, particularly if you're targeting only Linux.
Note that "git", for example, doesn't use them at all; instead it simply has a moderately-complex (but comprehensible) Makefile.
I'm writing Perl t/*.t tests for an existing project. During development, I'd like to use 'prove' to run select tests at arbitrary depths in the module directory hierarchy. I've created some t/ directories at the same depth as the *.pm files I'd like to test. Unfortunately, the lib/ at the base of the project's code is not in #INC.
What's the best way to automatically detect and add the path to #INC? I've looked at the -b option to prove and blib in general but they don't seem to work (they take the pwd and append blib/lib to it and add that to #INC). Ideally, the solution would not require an environment variable or installing the modules and would accommodate a number of working copies of the same code.
Is my approach wrong? Is there something obvious I'm missing? CPAN modules seem to solve this through installation or copied code blocks at the top of *.t files (yuck).
Edit:
Structure looks like:
/home/user/proj/branch\_foo/lib/First/Second/Third.pm
/home/user/proj/branch\_foo/lib/First/Second/t/third.t
This works:
~/proj/branch\_foo/lib/First/Second$ prove -I../..
But I'd like:
~/proj/branch\_foo/lib/First/Second$ prove -r
Or:
~/proj/branch\_foo/lib/First/Second$ prove t/third.t
So I can do:
~/proj/branch\_foo/lib$ prove -r
Instead of:
~/proj/branch\_foo/lib$ prove -I. -r
Maybe I just have to use -I and deal with it.
prove has an -I command line option:
-I Library paths to include.
Can you specify the paths using that option?
Update:
Thanks for providing the layout. I cannot think of a quick solution right now, but maybe you can use .proverc files in the appropriate directories to cut down on the typing required. I am not sure how multiple .proverc files interact with the -r option but this is something to look into.
This is exactly why the blib module exist. It looks in the current directory then its parent directories looking for blib/lib to add to #INC. It's part of the Perl standard library, so you should already have it.
From somewhere under t/ you can use the -M switch to load blib:
% perl -Mblib test.t
If you want to use it with prove
% perl -Mblib prove test.t
I think that's supposed to be the same thing as the -b switch in prove, but that last time I tried it (long, long ago) it didn't work. Maybe they've fixed it to work like blib.pm:
% prove -b test.t
Note that this requires you to build your distro first rather than test from lib/, but you should be doing that anyway. :)
You can set the environment variable PERL5LIB (as described in perldoc perlrun) which will cause perl to prepend the colon-separated paths to your #INC:
% export PERL5LIB=/absolute/path/to/your/libraries
% cd into/part/of/your/test/suite
% prove -r