I have been handed a binary package that I am integrating into a Yocto build.

When dnf runs it complains about missing dependencies. These are standard libraries of course but the culprit is the incompatible version. The software runs fine when I install it on the target using the script/tar installation it comes with. Needless to say that YP packaging QA complains about this already when assembling the package. However, there I can silence the complaints with INSANE_SKIP.

Unfortunately I have not found a method doing the same when the package is installed by the image class.

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 xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libdl.so.2(GLIBC_2.1) needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libgcc_s.so.1 needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libgcc_s.so.1(GCC_3.0) needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libm.so.6 needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libm.so.6(GLIBC_2.0) needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libm.so.6(GLIBC_2.1) needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libpthread.so.0 needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libpthread.so.0(GLIBC_2.0) needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libpthread.so.0(GLIBC_2.1) needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libpthread.so.0(GLIBC_2.2) needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides libpthread.so.0(GLIBC_2.3.2) needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides librt.so.1 needed by xxx-single-group-0.1-r0.cortexa53_crypto
  - nothing provides librt.so.1(GLIBC_2.2) needed by xxx-single-group-0.1-r0.cortexa53_crypto
(try to add '--skip-broken' to skip uninstallable packages)


--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

Can you show the recipe that you wrote for the blob?

Alex

On 6/7/22 12:44 PM, Alexander Kanavin wrote:

Can you show the recipe that you wrote for the blob?

Not exactly as is because of customer names, but below is a sanitized version:


SUMMARY = "Binary Stuff"

LICENSE = "CLOSED"

SRC_URI = "file://binary_installer.tgz \
          "

do_install() {

    install -d -m 0755 ${D}/opt/binstuff

    tar cf - -C ${WORKDIR}/opt/binstuff . | tar xf - -C ${D}/binstuff

}

FILES:${PN} = "/opt/binstuff"


RDEPENDS:${PN} += "libsystemd libudev libgpiod wayland"
INSANE_SKIP:${PN} += "ldflags file-rdeps arch staticdev"

The recipe itself builds just fine and creates the RPM package. However, the some of the binaries inside the package have been built against shared libs of older versions. The libs are there of course but with the wrong version. Adding file-rdeps to INSANE_SKIP addresses this at build time. But when installing the package in the rootfs dnf does a dependency check which then fails.

I don't know if there is an elegant way of overriding dnf to force installation of the package.

Alex

On Tue, 7 Jun 2022 at 20:59, Rudolf J Streif <rudolf.streif@...> wrote:

I have been handed a binary package that I am integrating into a Yocto
build.

When dnf runs it complains about missing dependencies. These are
standard libraries of course but the culprit is the incompatible
version. The software runs fine when I install it on the target using
the script/tar installation it comes with. Needless to say that YP
packaging QA complains about this already when assembling the package.
However, there I can silence the complaints with INSANE_SKIP.

Unfortunately I have not found a method doing the same when the package
is installed by the image class.

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
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libdl.so.2(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libgcc_s.so.1 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libgcc_s.so.1(GCC_3.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6(GLIBC_2.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libm.so.6(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.0) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.1) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides libpthread.so.0(GLIBC_2.3.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides librt.so.1 needed by
xxx-single-group-0.1-r0.cortexa53_crypto
- nothing provides librt.so.1(GLIBC_2.2) needed by
xxx-single-group-0.1-r0.cortexa53_crypto
(try to add '--skip-broken' to skip uninstallable packages)


--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

Can you drop insane_skip for a moment and show what errors then happen?

Yes, thank you.

ERROR: xxx-single-group-0.1-r0 do_package_qa: QA Issue: /opt/binstuf/linux-allwinneryocto-armle-opengles_2.0-obj/lib/libfbxsdk.so contained in package xxx-single-group requires libpthread.so.0(GLIBC_2.2), but no providers found in RDEPENDS:xxx-single-group? [file-rdeps]

There are many more of these errors.

Objdump on libfbxsdk.so:

Version References:
  required from libgcc_s.so.1:
    0x0b792650 0x00 12 GCC_3.0
  required from libpthread.so.0:
    0x0d696912 0x00 10 GLIBC_2.2
    0x09691972 0x00 07 GLIBC_2.3.2
    0x0d696911 0x00 05 GLIBC_2.1
    0x0d696910 0x00 03 GLIBC_2.0
  required from libc.so.6:
    0x0d696912 0x00 11 GLIBC_2.2
    0x0d696917 0x00 09 GLIBC_2.7
    0x0d696911 0x00 08 GLIBC_2.1
    0x0d696913 0x00 06 GLIBC_2.3
    0x09691f73 0x00 04 GLIBC_2.1.3
    0x0d696910 0x00 02 GLIBC_2.0

Objdump on libpthread.so.0:

Version definitions:
1 0x01 0x0e2f2c50 libpthread.so.0
2 0x00 0x06969197 GLIBC_2.17
3 0x00 0x06969198 GLIBC_2.18
        GLIBC_2.17
4 0x00 0x06969188 GLIBC_2.28
        GLIBC_2.18
5 0x00 0x069691b0 GLIBC_2.30
        GLIBC_2.28
6 0x00 0x069691b1 GLIBC_2.31
        GLIBC_2.30

The versions don't match hence dnf throws an error. I guess I can defer the error with INSANE_SKIP += "file-rdeps" but then it comes up again when installing.

Alex

On Tue 7. Jun 2022 at 22.57, Rudolf J Streif <rudolf.streif@...> wrote:

On 6/7/22 12:44 PM, Alexander Kanavin wrote:
> Can you show the recipe that you wrote for the blob?

Not exactly as is because of customer names, but below is a sanitized
version:


SUMMARY = "Binary Stuff"

LICENSE = "CLOSED"

SRC_URI = "file://binary_installer.tgz \
           "

do_install() {

     install -d -m 0755 ${D}/opt/binstuff

     tar cf - -C ${WORKDIR}/opt/binstuff . | tar xf - -C ${D}/binstuff

}

FILES:${PN} = "/opt/binstuff"


RDEPENDS:${PN} += "libsystemd libudev libgpiod wayland"
INSANE_SKIP:${PN} += "ldflags file-rdeps arch staticdev"

The recipe itself builds just fine and creates the RPM package. However,
the some of the binaries inside the package have been built against
shared libs of older versions. The libs are there of course but with the
wrong version. Adding file-rdeps to INSANE_SKIP addresses this at build
time. But when installing the package in the rootfs dnf does a
dependency check which then fails.

I don't know if there is an elegant way of overriding dnf to force
installation of the package.


>
> Alex
>
> On Tue, 7 Jun 2022 at 20:59, Rudolf J Streif <rudolf.streif@...> wrote:
>> I have been handed a binary package that I am integrating into a Yocto
>> build.
>>
>> When dnf runs it complains about missing dependencies. These are
>> standard libraries of course but the culprit is the incompatible
>> version. The software runs fine when I install it on the target using
>> the script/tar installation it comes with. Needless to say that YP
>> packaging QA complains about this already when assembling the package.
>> However, there I can silence the complaints with INSANE_SKIP.
>>
>> Unfortunately I have not found a method doing the same when the package
>> is installed by the image class.
>>
>> 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
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libdl.so.2(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libgcc_s.so.1 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libgcc_s.so.1(GCC_3.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6(GLIBC_2.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libm.so.6(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.0) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.1) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides libpthread.so.0(GLIBC_2.3.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides librt.so.1 needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>>     - nothing provides librt.so.1(GLIBC_2.2) needed by
>> xxx-single-group-0.1-r0.cortexa53_crypto
>> (try to add '--skip-broken' to skip uninstallable packages)
>>
>>
>> --
>> Rudolf J Streif
>> CEO/CTO ibeeto
>> +1.855.442.3386 x700
>>
>>
>>
>>
--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

-- 
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

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

Experiment with using a virtual provider. It may be possible to just map the dependency manually to

what is already there.

If you _know_ that your dependency is truly isolated to your recipe, you may be able to set RPROVIDES

values in your recipe so the resulting RPM thinks the dependencies are met internally.

Patch package_rpm.bbclass to add a guard variable around the setting of splitpreinst. Add that

guard variable to your recipe so it selectively turns off the pre-install checks for that particular package.

Or just check for files-rdeps in INSANE_SKIP and do the same thing...

Yeah well, that's not really a good solution unless it's upstreameable.

Stop fighting RPM and switch to a different package type like IPK.

That would probably only work if the dependency mechanism is different for IPK. I have not checked that.

..Ch:W..

--

"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire

-- 
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

I think what should help you is
EXCLUDE_FROM_SHLIBS = "1"
which disables poking into libraries to auto-generate those
dependencies that otherwise cause both qa and dnf errors.

Alex

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?

Cheers,

Richard

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

On Mon, 2022-06-13 at 13:08 -0700, Rudolf J Streif wrote:

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.

In glibc different architectures implemented different functionality at
different times so the symbol versions don't match cross platform. I
therefore wondering if it was an architecture mismatch or whether it
was an older obsolete ABI we didn't show by default somehow.

What puzzles me is that in theory you should have seen a different
error about the architecture of the binaries not matching the target
though?

Cheers,

Richard

On 6/13/22 2:32 PM, Richard Purdie wrote:

On Mon, 2022-06-13 at 13:08 -0700, Rudolf J Streif wrote:

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.

In glibc different architectures implemented different functionality at
different times so the symbol versions don't match cross platform. I
therefore wondering if it was an architecture mismatch or whether it
was an older obsolete ABI we didn't show by default somehow.

It was definitely an architecture mismatch. I checked the architecture of the files with objdump.

What puzzles me is that in theory you should have seen a different
error about the architecture of the binaries not matching the target
though?

That is what threw me off in the first place. I simply checked the versions. They were off but I could not explain why. The architecture explains it as you say. When scrolling through the objdump output the architecture eventually caught my eye.

Thanks,
Rudi

Cheers,

Richard

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700