On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote:
On Fri, 22 Oct 2021 11:09:27 -0400 Tom Rini trini@konsulko.com wrote:
Hi,
On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote:
On Fri, 22 Oct 2021 12:09:19 +0200 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 10/21/21 15:00, Marek Behún wrote:
BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu platform in Kconfig?
We should only use 'imply' for suggested settings and never for hard requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it for mvebu would be redundant.
In an OS distribution we only want to ship a single version of mkimage. So it is good to elimate symbol CONFIG_MXS.
How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO.
Tom wrote regarding this aspect in https://lists.denx.de/pipermail/u-boot/2021-September/460251.html:
"if we're building a generically useful tool, we don't want another symbol for it."
OK, so mkimage and dumpimage should be always generic and always support all platforms, that makes sense, since the tools can be installed as a distribution package.
But I still think it should be possible to cripple these tools if the developer wants to disable libcrypto due to embedded environment.
Well, I don't think this is the real question here, is it? I think the tools part is clear: distros want to build just mkimage, supporting as many platforms as possible, and might need to avoid OpenSSL. This should be covered by TOOLS_LIBCRYPTO=[yn] and "make tools-only_defconfg && make tools", and Samuel's patch actually fixes the build (at least somewhat, I still get link errors).
The problem is, are distros doing a tools-only build, for tools, or are they doing it per board? Like, hey, ugh, OpenEmbedded uses sandbox_defconfig and cross_tools as the targets. That's not quite what I was hoping to see. So I want to know everyone else is doing, rather than we hope they're doing.