<div dir="ltr">FWIW: the later is what I did in morty based build to get multilib working with allarch.<div><br></div><div>It was actually combination of both, in some cases the dependency was already pulled by something else and it was relatively safe to drop from allarch recipe (e.g. I did that for ca-certificates), in some cases I've just dropped allarch.</div><div><br></div><div>I also don't like building things twice, we have allarch web apps which have runtime dependency on web engine (which includes chromium build) and I really don't want to build chromium twice just to satisfy allarch dependencies, when we really want to have just one chromium in the rootfs in the end. So it's not only the multilib toochain and small things like openssl, but it can get huge. Building small allarch web app multiple times (per TUNE_PKGARCH) on the other hand is relatively small price to pay.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 26, 2018 at 11:07 AM <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2018-07-26 at 14:53 +0800, Kang Kai wrote:<br>
> On 2018年07月26日 06:47, <a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a> wrote:<br>
> > There is a bigger problem though since the allarch recipe signature<br>
> > filtering doesn't change what bitbake will actually build, only how<br>
> > its<br>
> > represented in sstate and the circumstances under which it would<br>
> > rebuild it. If ca-certificates DEPENDS on openssl, it will build<br>
> > openssl whether you're targeting core-image-sato or lib32-core-<br>
> > image-<br>
> > sato. This potentially means you can end up in a situation where it<br>
> > wouldn't build lib32-openssl if nothing else in lib32-core-image-<br>
> > sato<br>
> > depended upon it more directly.<br>
> <br>
> That's why extend rdepends of allarch package with all multilib<br>
> variant. <br>
> In bitbake inner environment, make ca-certificates depends on<br>
> openssl, lib32-openssl and even libn32-openssl for qemumips64. It may<br>
> cost a little more build time(I didn't test yet), but the dependency<br>
> relationship is fixed and make sure that all multilib version<br>
> of openssl exist in 'oe-core-repo' which is used for do_rootfs.<br>
> <br>
> When build ca-certificates, both openssl and lib32-openssl will be <br>
> built. And when write package of ca-certificates, remove openssl and<br>
> lib32-openssl from RDEPENDS and keep noarch-openssl. <br>
> And make both openssl and lib32-openssl provides noarch-openssl. Then<br>
> some tweak according image multilib type could be done at then end<br>
> of do_rootfs.<br>
<br>
Requiring that all variants of openssl build in order to build ca-<br>
certificates will have huge build time impact as it will need to build<br>
both multilib toolchains.<br>
<br>
At that point we'd probably be better either building allarch recipes<br>
twice (which I don't like), or, banning non-allarch dependencies from<br>
allarch recipes. If a recipe needs a non-allarch dependency we'd make<br>
it non-allarch. We may just have to accept the latter...<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>