On 2021-10-22, Tom Rini wrote: > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: >> On Fri, 22 Oct 2021 11:09:27 -0400 >> Tom Rini <tr...@konsulko.com> wrote:
>> > 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.schucha...@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. Thanks for bringing this to my attention! In Debian, the u-boot-tools package is built using tools-only, and for each of the board-specific targets, it still ends up building the relevent tools, but we throw them away and do not ship them in any packages. With 2021.10, the board-specific builds made it harder to avoid openssl with the corresponding tools, and I reluctantly added a dependency on openssl... (which is technically permitted in Debian, having declared openssl as a system library to avoid the GPL incompatibilities, but ... meh.) I also have been doing some packaging of u-boot for GNU Guix, where I suspect the stance wouldn't be as willing to accept such a compromise... So... I would *love* an option to be able to build a board-only config without any of the tools; do some boards use board-specific tools as part of their build processes? live well, vagrant
signature.asc
Description: PGP signature