All,
To answer my own question with a solution that is apparently working well.
For all recipes/packages that should be used at build time only but not to be
put in an image as opposed to the "otherpackage" that should get put into the
image:
* Manual in a conf file or function on bb.event.ConfigParsed to be of
global significance.
* Add a PREFERRED_RPROVIDER_<package> = "otherpackage" for each of them
[PREFERRED_RPROVIDER is surprisingly undocumented even though specific Yocto
use will prompt the user to set it!]
* Anonymous python in a conf file, processing ${PACKAGES} per recipe that
should be build-only
* Parse and rewrite RDEPENDS per package using
bb.utils.explode_dep_versions2 and bb.utils.join_deps to replace any reference
to a build time only package with "otherpackage"
* Append "build-deps" to INSANE_SKIP_<package> so that the delta between
build and runtime needs doesn't matter. Insane.bbclass apparently doesn't check
the explicit PREFERRED_RPROVIDERS to say "ok anyway".
* Add a PACKAGE_EXCLUDE_<pn> for all ${PACKAGES} (doesn't work for deb
as I have understood from docs but works fine for rpm as it seems)
This ensures that on recipe processing (including sysroot handling) all the
"normal" recipes are used, but none of the packages generated by normal recipes
go into the image then because "otherpackage" will be used then.
The method also tries to stay away from too many implementation details to be
somewhat portable hopefully across future Yocto versions.
It appears to work here at first glance. Your mileage may vary.
Hope this helps,
Heinz
From: [email protected] <[email protected]> On Behalf Of
Heinz Wrobel via Lists.Yoctoproject.Org
Sent: Thursday, January 30, 2020 11:57
To: [email protected]
Cc: [email protected]
Subject: [EXT] [yocto] Not adding glibc to an image and avoiding RDEPENDS
problem?
Caution: EXT Email
Hi,
I want to build an image that does in the end NOT contain the virtual/libc used
for building the elements of the image because the final target libc is
provided pre-built in a different way through another recipe and package. [Yes
I understand the version risks]
Given that the virtual/libc sysroot is still needed to build packages properly,
I thought that simply not packaging virtual/libc and then adding in the other
package into the image would do the trick.
"dtc" is my unmodified test recipe for the concept.
I must be missing some fine point however, because now I can't even build the
test recipe anymore:
ERROR: dtc-1.5.1-r0 do_package_qa: QA Issue: /usr/lib/libfdt.so.1 contained in
package dtc requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers
found in RDEPENDS_dtc? [file-rdeps]
ERROR: dtc-1.5.1-r0 do_package_qa: QA Issue: /usr/lib/libfdt.so.1 contained in
package dtc requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
RDEPENDS_dtc? [file-rdeps]
ERROR: dtc-1.5.1-r0 do_package_qa: QA Issue: /usr/lib/libfdt.so.1 contained in
package dtc requires libc.so.6()(64bit), but no providers found in
RDEPENDS_dtc? [file-rdeps]
ERROR: dtc-1.5.1-r0 do_package_qa: QA Issue: /usr/lib/libfdt.so.1 contained in
package dtc requires ld-linux-aarch64.so.1()(64bit), but no providers found in
RDEPENDS_dtc? [file-rdeps]
ERROR: dtc-1.5.1-r0 do_package_qa: QA run found fatal errors. Please consider
fixing them.
I found the change that RDEPENDS are no longer recursively checked, so I
thought I should find how the dependency is directly resolved and missed via
bitbake -e.
Bitbake -e shows that RDEPENDS for dtc is empty, i.e., a shared library glibc
file based runtime dependency usually must be filled by some other magic that I
can't seem to grasp.
I have not seen receipes all over the place explicitly specifying an RDPENDS
for the libc used.
The tmp/pkgdata/*/runtime/ file for my other package clearly shows
FILERPROVIDES for exactly the "missing" files.
I could decide to ignore file-rdeps, but I'd rather "consider fixing them".
I also did read the "shlibdeps" bullet in "Automatically Added Runtime
Dependencies" and then grepped quite a bit through meta/classes and bitbake
itself. File-rdeps checking does not seem to check on the package database.
I couldn't figure out the mechanism that a) causes the error, and that b) would
allow me to fix it properly.
What am I missing about implicit runtime dependency handling for the selected
libc?
Thanks,
Heinz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#48248): https://lists.yoctoproject.org/g/yocto/message/48248
Mute This Topic: https://lists.yoctoproject.org/mt/70946916/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
