On 6/8/22 8:54 AM, Richard Purdie wrote:
On Tue, 2022-06-07 at 18:17 -0700, Rudolf J Streif wrote:On 6/7/22 4:36 PM, Chuck Wolber wrote:>> Is there an elegant way around it? >> >> >> Error: >> Problem: conflicting requests >> - nothing provides libdl.so.2 needed by >> xxx-single-group-0.1-r0.cortexa53_crypto >> - nothing provides libdl.so.2(GLIBC_2.0) needed byCould this be considered a bug in the package_rpm.bbclass? It seems to me that if you skip files-rdeps, we might not want to be adding anything into splitpreinst. Otherwise it seems silly to tell insane.bbclass to skip something that RPM is going to ding you on later anyway. Or maybe I am confused... In any case, I believe what you may be seeing can be viewed as an RPM-ism, and not necessarily a yocto-ism per se. So you might consider trying one of the following to work around the problem:It's Yocto that creates the spec file for rpm. Apparently, besides relying on what is declared in RDEPENDS, it actually iterates over the files and appends the dependencies (and their versions). It results in this: Requires: libc.so.6 Requires: libc.so.6()(64bit) Requires: libc.so.6(GLIBC_2.0) Requires: libc.so.6(GLIBC_2.1) Requires: libc.so.6(GLIBC_2.1.3) Requires: libc.so.6(GLIBC_2.17)(64bit) Requires: libc.so.6(GLIBC_2.2) Requires: libc.so.6(GLIBC_2.28)(64bit) Requires: libc.so.6(GLIBC_2.3) Requires: libc.so.6(GLIBC_2.3.4) Requires: libc.so.6(GLIBC_2.4) Requires: libc.so.6(GLIBC_2.7) Removing anything but the first two lines would probably do the trick. So if file-rdeps is declared in INSANE_SKIP it should simply only use the declared RDEPENDS and not analyze the files.If that works at runtime it makes me wonder if our glibc shouldn't be providing some of those things? What does our glibc package say it is providing? How does that compare to what objdump says?
That's the objdump on libc.so.6 on the target (aarch64, Honister): Version definitions: 1 0x01 0x0865f4e6 libc.so.6 2 0x00 0x06969197 GLIBC_2.17 3 0x00 0x06969198 GLIBC_2.18 GLIBC_2.17 4 0x00 0x06969182 GLIBC_2.22 GLIBC_2.18 5 0x00 0x06969183 GLIBC_2.23 GLIBC_2.22 6 0x00 0x06969184 GLIBC_2.24 GLIBC_2.23 7 0x00 0x06969185 GLIBC_2.25 GLIBC_2.24 8 0x00 0x06969186 GLIBC_2.26 GLIBC_2.25 9 0x00 0x06969187 GLIBC_2.27 GLIBC_2.26 10 0x00 0x06969188 GLIBC_2.28 GLIBC_2.27 11 0x00 0x06969189 GLIBC_2.29 GLIBC_2.28 12 0x00 0x069691b0 GLIBC_2.30 GLIBC_2.29 13 0x00 0x069691b1 GLIBC_2.31 GLIBC_2.30 14 0x00 0x069691b2 GLIBC_2.32 GLIBC_2.31 15 0x00 0x069691b3 GLIBC_2.33 GLIBC_2.32 16 0x00 0x069691b4 GLIBC_2.34 GLIBC_2.33 17 0x00 0x0963cf85 GLIBC_PRIVATE GLIBC_2.34I don't exactly know how the glibc versioning works. I suppose the API versions are defined by the Version file of the various components.
However, when I did more analysis on the libraries whose libc versions did not seem to be met, I found out that they were libraries for a different architecture (x86_64) which were not supposed to be included. Now I wonder if the check validates version compatibility only or also checks architecture compatibility. However, if the latter then the error message does not convey that.
Thanks, Rudi
Cheers, Richard
-- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700
OpenPGP_0x8D8CA82927339B75.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57326): https://lists.yoctoproject.org/g/yocto/message/57326 Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-