Thanks, Richard. I was sidetracked by other stuff, hence the delay. Please see below.

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 by 

Could 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.34

I 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