I have built images using yocto(core-image-minimal). I need "libtinfo" library to run my application, but it is not part of rootfs.
I could see the library was built and available under "cortexa7hf-neon-poky-linux-gnueabi" folder, but it is not available in rootfs. I have added using IMAGE_INSTALL_append.
My doubt here is, if the library is not required for rootfs(core-image-minimal) then it should not built.
Why the yocto built that library? similar behavior was observed with libudev library also.
Before answering your question, if you have an application which depends on "libtinfo" and your application is also build using yocto (say sample_app.bb), then you should use
DEPENDS += "libtinfo"
RDEPENDS_${PN} += "libtinfo"
This will instruct yocto to include the library in rootfs as your application needs it for runtime.
My doubt here is, if the library is not required for
rootfs(core-image-minimal) then it should not built.
Assume you have source for a package which produces binary and also library i.e for example source for kmod produces libkmod and also modprobe, insmod, rmmod. In such cases recipes are written in such a way to produce two different package (based on configuration you can see *.rpm or *.ipk) files i.e kmod_*.ipk/rpm and libkmod2_*.ipk/rpm.
Based on your real requirement of application you can either use kmod or libkmod in RDEPENDS.
In your case, libtinfo is build inside ncurses package which may not be required in rootfs by any package.
Why the yocto built that library? similar behavior was observed with
libudev library also.
By default the recipe for the source component ncurses or systemd includes the configuration (do_configure) for libtinfo and libudev respectively. But it is not included in rootfs, as none of the software needs it during runtime.
You can always check the dependency graph using
bitbake -g <recipe name>
as mentioned here.
Related
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?"
I am writing a bitbake recipe to deploy a third party pre-built tool, similar to this wiki page: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
However, I have a Release and Debug pre-build versions of the tool available as *.so files. How do I distinguish inside the recipe which one of both build types I shall deploy?
Thanks and regards,
Martin
You can have two different virtual recipes each with their own .so file. This then warrants a selection in a configuration file (with PREFERRED_PROVIDER_virtual/my-recipe), so either in a machine or distro configuration file. This is probably preferred if you consider having release and debug distros.
A second option is to install the libraries in two different paths, in two different PACKAGES (use FILES_my-package for that) and make them RCONFLICTS_my-package each other to be sure they can't both be in the rootfs. After that, you could write a pkg_postinst_my-package() task specific to each package that actually move the library from the "different" path to the intended one. This will be run both at build time when creating the rootfs and at runtime on first boot, so you need to make sure to exclude one or the other (it's usually done by checking if ${D} exists, which does at build time but not runtime).
c.f.: http://docs.yoctoproject.org/dev-manual/dev-manual-common-tasks.html#post-installation-scripts
If you can manage to have both libraries installed in your rootfs and select the one you want with the LIBRARY_PATH environment variable, a simple recipe, with two packages with each library in a different location, will be sufficient.
I have a project that could be built with the Yocto build system to generate a full disk image. According to the existing procedure, I can get only a full disk image that should be flashed on SD card.
And this does not suit my needs because I can't flash the image on the board. In my case, I need to build a certain project (that currently has a recipe) to an executable. (This project currently is a part of the full disk that is built with Yocto)
So I am wondering, is it possible to extract this executable (and the libraries that this executable depends on) from Yocto build files, so that I could copy and install it on the board? Which possibilities do I have to do this? Do I have some quick and dirty way to do this?
P.S: I heard something about that Yocto can provide a package for a certain project, that could be installed by the corresponding package manager on the board. On the board installed dpkg package manager.
It's a solution to add tar.gz to your IMAGE_FSTYPE.
After building the image, you can extract the executable you were looking for from the created archive.
Or you add the output format you need for your target and install the full image.
I have a recipe which successfully invokes a legacy build command to cross-compile a target.
As a side effect it produces some custom native tools that are used in the build.
I want to reap those tools into a -tools-native package to allow other recipes to depend the main package to access the artifacts, and use the -tools-native package to further process those artifacts.
I can build such a native package as simply as adding:
PROVIDES = "${PN} ${PN}-tools-native"
SYSROOT_DIRS += "/"
PACKAGES += "${PN}-tools-native"
FILES_${PN}-tools-native += "/native-bin/*"
and having the install section install the native tools to /native-bin/
but yet it somehow isn't a real native package, and when DEPENDS'd by an additional recipe the native-bin artifacts are installed inrecipe-sysrootinstead ofrecipe-sysroot-native`
I also have to install the tools 0644 or bitbake tries to strip them (and fails, as they are native build).
Because the native tools are already generated by the legacy build commands, I don't need to actually invoke as a -native recipe variant.
It's a long process, I don't want to run it twice, either.
Currently I work around it by having the other recipes DEPEND on recipe-native-tools and fixup the permissions and PATH
But what's the proper way to do this?
This is generally handled by separate recipes. There is no mechanism to share native binaries from target recipes as their task hashes have the wrong kinds of information in them (they change depending on the target architecture).
Target recipes don't install their bindir/sbindir into the sysroot since we can't run them and as you mention, they're the wrong architecture so they confuse strip and so on.
You could try having a native recipe which depended upon this target recipe and which installs the binaries saved by the target recipe somewhere into its ${D} at do_install. That may well give some warnings since in general native recipes shouldn't depend on target recipes but is probably your best option if you can't build twice.
I’m quite new to Yocto build system and I’m struggling on something I don’t understand. Actually, what’s the difference between :
DEPENDS= “foo”
and
DEPENDS=“foo-native”
I mean, I know the suffix -native indicates that the component foo will be built to run on the native host machine, but what are the consequences for the target machine ?
What does it change to switch a dependency to a -native dependency ?
As, in any case, everything is pre-built and pre-packaged on the host machine, where is the difference ?
DEPENDS are build time dependencies which allow you to specify which packages need to exist prior to building your recipe. So DEPENDS = "foo" would explicity state that the foo package needs to be successfully built and installed prior to my package starting it's do_configure (it might just be a dependency for do_compile, but I think it's do_configure) process. Using a -native for DEPENDS says that packages native components need to exist as well. A good example of this is the Google protobuf package. It has both native and target components, and you generally need both to use it. The protobuf-native package would include creating the protoc compiler, which would be required to build a pacakage that needs the protoc compiler to generate content. It would also need the protbuf package for it's runtime components as well to link against.
Generally, there are no consequences so to speak. The protoc in my example above doesn't exist on the target. That answer may depend on the package though, so it's not so simple to say it has none. Generally though, use -native if you need a native tool to help you build a target object.