For an application I am running, there is a run time error as it cannot find libwayland-client.so.0 shared object. How do I know which package provides it and where do I add it. I tried as shown below but it gave me a Nothing PROVIDES error.
CORE_IMAGE_EXTRA_INSTALL += "libwayland-client"
You don't typically work with single files when building Yocto images
In reverse order
You install packages to the image
You build packages by using a recipe
You find (or as a last resort write) recipes as part of layers.
Generally when something is missing you take the following steps:
Check the layerindex https://layers.openembedded.org/layerindex/branch/master/recipes/?q=wayland It tells you that there is a recipe called wayland in layer openembedded-core
Add the layer in question. openembedded-core is already contained in Yocto's poky (directly under the name meta, just to confuse the newcomer...), so nothing to add in this example
Create the environment listing of the recipe in question, bitbake -e wayland >wayland.env
Check what packages the recipe in question creates grep ^PACKAGES= wayland.env. In this case it is easy because there is really only one package wayland (-debug, -dev etc. are special purpose that would not contain the library)
Add a package to the image by its package name. How to do that exactly depends on the image type you create. The variable name given in the question works for some images, but not all. Search for IMAGE_INSTALL in the manual https://www.yoctoproject.org/docs/2.6.1/mega-manual/mega-manual.html for other options.
Once you have built the recipe in question you can also check what files are contained in a package (In this case recipe name and package name are identical, but that is not always the case. Some recipes build more than one package suitable for installation, so obviously they need to use different names)
$ oe-pkgdata-util list-pkg-files wayland
wayland:
/usr/lib/libwayland-client.so.0
/usr/lib/libwayland-client.so.0.3.0
/usr/lib/libwayland-cursor.so.0
/usr/lib/libwayland-cursor.so.0.0.0
/usr/lib/libwayland-server.so.0
/usr/lib/libwayland-server.so.0.1.0
Related
I am building a Yocto image. There are some GPLv3 libraries which are required only at build time. I have put GPLv3 as INCOMPATIBLE_LICENSE and whitelisted the libraries which are required at build time. But these libraries are getting into the final image. How can I restrict them into the final image and only use them at the build time?
If we think about the Yocto basics, we know that everything goes into the final image is a collection of recipes providing packages that are collected together in a single root file system.
So, what makes a recipe goes into the final rootfs ?
Added via IMAGE_INSTALL.
Be set as RDEPENDS of another recipe.
You need to analyse that deeply to find out what goes into your final rootfs.
Also, you may not find it obvious in the content of IMAGE_INSTALL by running:
bitbake -e <your_image_recipe> | grep ^IMAGE_INSTALL=
but, you may see some packagegroups that are shipped. A packagegroup is a group that RDEPENDS on a list of other recipes.
So, you need to carefully analyse them (if found) to see what provides the lib you want to inhibit from rootfs.
packagegroups usually gets shipped dynamically via IMAGE_FEATURES variable.
So, those are the most important points that are responsible of shipping a recipe to the rootfs. So, Analyse your wanted recipe.
Is it an RDEPENDS of another recipe ?
Find out where exactly it gets called to be shipped.
Removing the installation of lib from do_install task by adding something like this in recipe e.g gdb as you said
do_install:append()
{
#remove the lib which you don't want to ship into image
}
And make sure the same lib is not added to FILES var in recipe
e.g FILES:${PN} += "< lib >"
PACKAGE_EXCLUDE worked for me. If packages listed under PACKAGE_EXCLUDE is getting into the final image, then this will raise an error.
Also if any other package has a runtime dependency on a package listed under PACKAGE_EXCLUDE, then this will raise an error too.
References:
https://docs.yoctoproject.org/ref-manual/variables.html#term-PACKAGE_EXCLUDE
https://git.yoctoproject.org/poky/tree/meta/conf/documentation.conf#n313
While building a Yocto image, BitBake fetches the files specified in layer recipes. When running bitbake, the process identifies missing files and tries to find them from mirrors.
Aside from searching the whole project for the missing file, is there a bitbake tool to identify a layer or recipe, given a broken package/file link?
One current example is:
expat-native-2.2.8-r0
tried, invalid: https://downloads.sourceforge.net/expat/expat-2.2.8.tar.bz2
use: https://github.com/libexpat/libexpat/releases/download/R_2_2_8/expat-2.2.8.tar.bz2
This question may be similar, but is out of date.
How do I find which layer is using the expat-native package?
I am trying to determine how I can find what recipe a source file from the build/tmp/work directory came from. Basically normally most of the recipes in the source folder are uri. Then get downloaded and installed to various temp folders. I want to create a patch for some of the files, but I can't seem to figure out which files belong to what recipes.
Thank you
Run oe-pkgdata-util find-path /path/on/target/to/file. This will give you the package installing the file. From there, run oe-pkgdata-util lookup-recipe <pkg-name>, this will give you which recipe is creating the package. That should be enough to find out which recipe you need to modify. You then need to check whether the file you want to modify is part of the recipe (Yocto artifact) or part of the software that the recipe builds. For the former, you can override the file, for the latter, you can create a patch (you can use devtool to help you create the patch).
I get it that Yocto eSDK is snapshot of pre-configured OpenEmbedded build system. But I want to verify that the custom library that I add as a new meta layer (say, meta-foo layer) becomes a part of eSDK. So, that the user applications may include the header files of this custom library, link against the *.a of this custom library and that the user applications may link in runtime against shared objects of this custom library.
So, is it enough to define in the recipe of this custom library just:
RPROVIDES = "custom_lib1.so custom_lib2.so ..."
... to tell bitbake to copy those *.so libraries to the RootFS?
And how to ensure that the header files of this custom library are copied to the appropriate place, say, /usr/include?
Not exactly, RPROVIDES is used for deliver package dependency, thus You need provide here recipe name.
Firstly You need to create recipe with will use do_install function into deliver needed binaries to ${D}${includedir}/. Then add created package (recipe) as RDEPENDS to nativesdk-packagegroup-sdk-host.bb recipe.
I have created my own recipe for building my SW, which requires native perl during building (e.g. invoking perl script for generating code). There is no problem if I add my recipe to an image and use bitbake to build my recipe with the image.
Now I also want to build SW with a populate SDK, but I found that when I generate the populate SDK, the native perl only contains a few modules without what is necessary to build my SW. I have found two ways to generate the populate SDK with additional perl modules:
Add TOOLCHAIN_HOST_TASK += "nativesdk-perl-modules" to my image .bb file before I generate the populate SDK
Add a bbappend file for nativesdk-packagegroup-sdk-host which includes "nativesdk-perl-modules" in RDEPENDS
For 1, it is an image-specific solution.
For 2, it is a global solution.
Now I am looking for a recipe-specific solution. Is there a solution where I could add some configuration in my recipe .bb file, and then I build populate SDK for any image which include my recipe will contains these additional native perl modules?
I'm afraid there isn't really a way for a specific recipe to hint at adding specific dependencies to an SDK. The closest thing I can think of would be to code something into anonymous python in something like an extra global class, where it checks the included target packages and then adds dependencies to TOOLCHAIN_HOST_TASK if the right target packages are being installed. Even this wouldn't detect non direct dependencies of your specific recipe.