Bitbake not using patch for gcc - yocto

I have a situation in a distribution based on Yocto 1.7 targetting ARM whereby I'd like to apply a patch to the cross-compiling GCC 4.9.
The regular bbappend override mechanism is not working for GCC, which is "special".
I have a gcc-cross_4.9.bbappend file which finds its target; but in other respects, it's as if it didn't exist. The patch isn't applied, in spite of removing all the stamp files to force a rebuild from do_unpack, do_patch and do_config onward.


The answer is: pay attention to what package is actually being subject to the do_unpack and do_patch. It is not gcc-cross or gcc, but gcc-source.
The various stages and configurations of gcc all share the unpacking steps from the gcc-source virtual package; if you target those with patch overrides, nothing happens because none of them execute any unpacking and patching steps.
It is a gcc-source-basenamed .bb file which controls these steps.
Thus, I simply renamed the .bbappend to target the gcc-source name and it worked.


I don't know how long you took to debug this, but an easy way is by executing
bitbake-layers show-appends | grep gcc
You will directly see if your bbappend is taken into account by yocto

Related

Changing revision for patched in-tree kernel module in Yocto

I've set successfully my Yocto build to patch one of the standard kernel modules, and I'd like to make it possible to update that (and possibly some others in the future) module only on the target system using kernel modules RPM file. The only problem is that the patched module is marked with the exact same revision as the original one, so the only way to update would be to force reinstall of all kernel modules.
Is there any way to manually change PR or a similar version-related parameter for a specific kernel module, or maybe tweak the Yocto project in some other way, so the RPM file built upon it would recognize that module as the only one in need of update?

Why is package included in Yocto rootfs?

I'm in the process of upgrading from Yocto Sumo to Yocto Dunfell. In this process there's quite a few packages getting added to the rootfs that wasn't there before and which I don't have use for. I would like to know why they are added? Which dependency triggers them to get added?
In previous versions of Yocto there was a pn-depends.dot file which provided this information. This has now been removed. All that is left is a task-depends.dot which I guess I should use, however it is harder to read as it lists dependencies between individual tasks and doesn't show why a certain package is added to the rootfs. The command bitbake -g <image-name> -u taskexp makes it slightly easier to read the file but it is still hard to understand as package names are not always the same as task names.
What is the preferred solution to get an answer to "why is included in my rootfs?"

Modifying core-image-minimal to only make rootfs

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'.

Preventing hardcode path in RPM SPEC file

I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.

Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.

Re-compiler QtEmbedded in OpenEmbedded without Examples

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.