Did you find some final solution? For me, we can make it enabled by default. Anyone could use custom defconfig in own layer.
Cheers, Andrej On 08/20/18 23:28, Andre McCurdy wrote: > On Mon, Aug 20, 2018 at 2:03 PM, Peter Kjellerstedt > <[email protected]> wrote: >>> -----Original Message----- >>> From: Andre McCurdy <[email protected]> >>> Sent: den 20 augusti 2018 22:23 >>> To: Khem Raj <[email protected]> >>> Cc: Richard Purdie <[email protected]>; Peter >>> Kjellerstedt <[email protected]>; Patches and discussions >>> about the oe-core layer <[email protected]> >>> Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on >>> virtual/crypt >>> >>> On Mon, Aug 20, 2018 at 12:45 PM, Khem Raj <[email protected]> wrote: >>>> On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie >>>> <[email protected]> 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 <[email protected]> >>>>>> --- >>>>>> 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 >> -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
