Fixing a recipe

Now, there’s no need to panic and think you need to go debug this yourself, remember, most of these packages are standard – mostly actually provided by the yocto project or third party itself. These errors are mostly caused by us using outdated sources with newer build tools, you’ll see this when you google it. So, I googled this, try to be specific like I did:

error: ‘%s’ directive argument is null [-Werror=format-overflow=] glibc yocto

What we’re looking for is bugs, patches and commits. I found:

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/626#note_422501

Going to changes, we can see what we need to do:

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/626/diffs?commit_id=566e1d61a500267c7849ad0b2552feec9c9a29a6

You could try getting patches and applying these but I prefer to just do it manually (to an extent) if it’s not too troublesome. This is because, again, we’re working from specific, sometimes deviated, branches. So a patch isn’t guaranteed to work and may argue that this patch wasn’t for this branch of code.

I highly recommend checking out the TipsAndTricks section of the yocto wiki as it’s got some great tips (well, obviously!). So, let’s use the first one, let’s fix our source:

https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe

So in our terminal, let’s run now:

devtool modify glib-2.0

Note: this package is a little strange in naming. Usually you wouldn’t include the version number, but for this one we have to. You’ll be able to tell the different because if it’s an underscore before the version number, don’t include, if a hyphen, do.

As you may read in the article, what this does is unpacks the source that it’s building from into a location called workspace which we can now modify. So, if you now navigate to your build directory and go to:

/[build directory]/workspace/sources/glib-2.0

Now go find those files and update them with those changes. Next, we need to apply those. Within the directory I’ve referenced above (within the glib-2.0 folder but no higher or lower in folder hierarchy). Now, these are git repo’s, if not, bitbake puts one there so we can track our changes and eventually.. build our own patch! Why is this great, it’s because the build directory was made at the start, we didn’t receive it, so when you share your system with people, you want it to be back as a patch in your source directory (or rather… in your recipes).

I may have just confused you a little if you’re new to yocto so let’s quickly just run up on that. Yocto is a build system. The source folder we started with is a bunch of “recipes” the build system consumes and follows, these recipes basically describe how to build a package or our image. The file contains where to grab sources, what functions to run as part of the build process, what flags to use with things like gcc anddd patches to apply. From now on, I’ll call these recipes to avoid confusing source of the build from source of the package that we’re debugging.

So, back to git and our patch work. We’ve gone and edited the files and made the amendments according to that patch, if you run the build again now, it’ll run the code from workspace and be all fine. But that’s not where we should stop. Within glib-2.0 do the following:

git add -A
git commit

It’ll ask you for a commit message, I like to copy in whatever the original author put to describe the issue and if I can, their details to give credit where due.

So why did we have to do that? Well, what yocto will do with our next command is take all the individual commits you make when running in the devtool environment, create a patch and then add this to the recipe we’re fixing – great right! It’s automated that for us too, starting to see why I enjoy it so much? Or why you, NI and really anyone maintaining an embedded system might want to use this tool..

In normal practice, you may want to run your build right here, this is because it might still not compile from the previous error, or a new one. So it’s nice and handy to keep this as the working source until it builds fully. I know from experience this’ll now build so I’m going to go ahead, update my recipe and close down this work:

devtool update-recipe glib-2.0
devtool reset glib-2.0

It’ll now say, you can delete that source directory (or you can keep it if you like). Personally, I like to delete them if I can just to avoid the chance it still builds from it. This is unless I keep hitting errors continuously, another thing you can do in this instance is try out a newer recipe if things just keep going wrong. This is what I did with qemu, the version from NI was 2.11 and I just kept hitting build errors where that version isn’t really cut out for x64 builds, when I replaced it with 4.2.0, due to a difference in dependencies here, I also had to update the libsdl2 recipe to the new version as well. Once I did this, it all worked and built qemu fine.