On 08/27/2018 02:42 AM, Andrej Valek wrote:
Did you find some final solution?
Since no one has replied, it seems that the answer is to omit the
virtual/crypt dependency.
For me, we can make it enabled by default. Anyone could use custom
defconfig in own layer.
Right.
I would be nice get the package update done since 1.27.x is
about a year old and M3 is yesterday/this week.
We can settle this potential dependency as a defect if someone
finds such a bug.
../Randy
Cheers,
Andrej
On 08/20/18 23:28, Andre McCurdy wrote:
On Mon, Aug 20, 2018 at 2:03 PM, Peter Kjellerstedt
<peter.kjellerst...@axis.com> wrote:
-----Original Message-----
From: Andre McCurdy <armccu...@gmail.com>
Sent: den 20 augusti 2018 22:23
To: Khem Raj <raj.k...@gmail.com>
Cc: Richard Purdie <richard.pur...@linuxfoundation.org>; Peter
Kjellerstedt <peter.kjellerst...@axis.com>; Patches and discussions
about the oe-core layer <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on
virtual/crypt
On Mon, Aug 20, 2018 at 12:45 PM, Khem Raj <raj.k...@gmail.com> wrote:
On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote:
busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by: Peter Kjellerstedt <peter.kjellerst...@axis.com>
---
meta/recipes-core/busybox/busybox.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
core/busybox/busybox.inc
index 8c6dbbaf9b..a8ba10d21c 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
many
common UNIX utilities into
HOMEPAGE = "http://www.busybox.net";
BUGTRACKER = "https://bugs.busybox.net/";
-DEPENDS += "kern-tools-native"
+# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
defined
+DEPENDS += "kern-tools-native virtual/crypt"
I'm not a bug fan of adding dependencies which might not be needed.
How
common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't
our default config?
yes perhaps it should be packageconfig
Busybox doesn't use PACKAGECONFIG. Conditional configuration is
handled by adding / removing cfg fragments and testing whether SRC_URI
contains "foo.cfg" (and also parsing the final .config within tasks
such as do_install). Unfortunately that approach doesn't work so well
for conditional build dependencies...
Our Busybox defconfig does enable CONFIG_USE_BB_CRYPT (and there's no
cfg fragment to disable it) so the virtual/crypt dependency isn't
needed in our default builds.
In our case we have our own defconfig. I am not responsible for it, it is
maintained by our busybox maintainer, and he has apparently decided that
we don't want CONFIG_USE_BB_CRYPT enabled.
Could you ask him about it? Maybe there's some advantage to it that isn't clear.
The general OE approach is to use system libraries when possible so
using external libcrypt does actually align to that.
Maybe we should use external libcrypt by default (with the option to
switch back to the built-in crypt functions via a cfg fragment)?
I can of course add the dependency via a bbappend, but having to do that
seems wrong given how the rest of busybox is configured (with defconfig
and cfg fragments) and where enabling some options that don't happen to
be enabled in the OE-Core default configuration will then break the build.
Disabling busybox's internal crypt functions doesn't seem like a very
common thing to want to do.
config USE_BB_CRYPT
bool "Use internal crypt functions"
default y
help
Busybox has internal DES and MD5 crypt functions.
They produce results which are identical to corresponding
standard C library functions.
If you leave this disabled, busybox will use the system's
crypt functions. Most C libraries use large (~70k)
static buffers there, and also combine them with more general
DES encryption/decryption.
For busybox, having large static buffers is undesirable,
especially on NOMMU machines. Busybox also doesn't need
DES encryption/decryption and can do with smaller code.
If you enable this option, it will add about 4.8k of code
if you are building dynamically linked executable.
In static build, it makes code _smaller_ by about 1.2k,
and likely many kilobytes less of bss.
//Peter
--
# Randy MacLeod
# Wind River Linux
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
