On 8/28/23 10:09, Max Krummenacher wrote:
On Mon, Aug 28, 2023 at 5:01 PM Max Krummenacher via
lists.openembedded.org <max.oss.09=gmail....@lists.openembedded.org>
wrote:
On Sun, Aug 27, 2023 at 11:23 PM Peter Kjellerstedt
<peter.kjellerst...@axis.com> wrote:
-----Original Message-----
From: Max Krummenacher <max.oss...@gmail.com>
Sent: den 27 augusti 2023 10:10
To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
<peter.kjellerst...@axis.com>
Cc: Max Krummenacher <max.krummenac...@toradex.com>; Randolph Sapp
<r...@ti.com>
Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the
default dependencies"
From: Max Krummenacher <max.krummenac...@toradex.com>
Hi
With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
dependencies") applied I'm getting a lot of these errors, i.e. qa
does miss libc and compiler provided libs:
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found
in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-
umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers
found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
Reverting the commit makes the build pass, alternatively adding
to depends in the recipe which is using the bin_package class
fixes it too:
DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
I'd prefer reverting removing the default dependencies over fixing
each of the recipes which do use the bin_package class to actually
install binaries running in the target user space.
Any opinions?
Bummer. I guess we will have to update our recipes individually
instead. :(
From the bugzilla entry [1] which added the feature and from the commit
adding the class [2] it looks to me that the class should simplify adding
binaries externally built for the target.
Having the users of the class having to add the used libc / compiler
shared objects to not trigger a qa warning seems really wrong to me.
Additionally I don't see the advantage in not installing the base
dependencies. Doing anything usefull in a build would need to build
them anyway for some other recipe, so one would save creating a few
hard links. Do I miss something here?
So IMHO a recipe which inherits the class and really does not like the
default dependencies should add the `INHIBIT_DEFAULT_DEPS = "1"`.
Adding the missing links, sorry about that:
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1592
[2]
https://www.openembedded.org/pipermail/openembedded-core/2012-September/067782.html
Thanks for bringing this to light Max. I have no opinion in this. I
understand not wanting to implicitly depending on anything. After all,
explicit is always nice for those that don't want to navigate the full
include chain to figure out recipe dependencies. It's also nicer for a
minimal build (though arguably not in this case because these are core
packages we're depending on).
If this is going to be the standard moving forward please let me know so
I can update this recipe accordingly.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186837):
https://lists.openembedded.org/g/openembedded-core/message/186837
Mute This Topic: https://lists.openembedded.org/mt/100987453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-