<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hello Everybody,<div><br></div><div><br></div><div>I checked how Yocto solved this issue, and they added â€”disable-neon configure flag when neon is not available. We can do the same in the Makefile. Below is the link to Yocto recipe.</div><div><br></div><div><a href="http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-crypto/botan/botan_2.9.0.bb">http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-crypto/botan/botan_2.9.0.bb</a><br><br><div id="AppleMailSignature" dir="ltr">Thank you,<div>Boris Krasnovskiy</div></div><div dir="ltr"><br>On Apr 13, 2019, at 5:54 PM, Christian Lamparter <<a href="mailto:chunkeey@gmail.com">chunkeey@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>On Saturday, April 13, 2019 11:08:38 PM CEST Rosen Penev wrote:</span><br><blockquote type="cite"><span>On Sat, Apr 13, 2019 at 7:07 AM Christian Lamparter <<a href="mailto:chunkeey@gmail.com">chunkeey@gmail.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Cc'd: BangLang Huang <<a href="mailto:banglang.huang@foxmail.com">banglang.huang@foxmail.com</a>></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Saturday, April 6, 2019 10:35:48 PM CEST Rosen Penev wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>According to rules.mk, -mfloat-abi=soft is used. This is causing build</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>failures with the botan library:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="https://downloads.openwrt.org/snapshots/faillogs/armeb_xscale/packages/botan/compile.txt">https://downloads.openwrt.org/snapshots/faillogs/armeb_xscale/packages/botan/compile.txt</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Is it sensical to change the default to softfp, as the error message suggests?</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>That's the error:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>#error "NEON intrinsics not available with the soft-float ABI.  Please use -mfloat-abi=softp or -mfloat-abi=hard"</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I think the best option would be to tell the package to disable neon in this</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>case, just like ffmpeg is doing already. If you can test:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>ifeq ($(CONFIG_SOFT_FLOAT),y)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>CONFIGURE_ARGS += --disable-neon</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>endif</span><br></blockquote></blockquote><blockquote type="cite"><span>That could work. I find it interesting that it's only the old ARM</span><br></blockquote><blockquote type="cite"><span>architectures that are getting compilation errors.</span><br></blockquote><span>Ah, that's because ARM's toolchain was recently changed in order to fix</span><br><span>the gcc 8.x error due to conflicting march vs mcpu compiler flags.</span><br><span></span><br><span>See PR 1913 for the gory details: <a href="https://github.com/openwrt/openwrt/pull/1913">https://github.com/openwrt/openwrt/pull/1913</a></span><br><span>Before that commit, botan would probably compile, but the binaries</span><br><span>may not work on the target system (didn't test so take this with a</span><br><span>load of salt).</span><br><span></span><br><span>But if you look on the botan's github issue tracker, you'll find that</span><br><span>someone reported a similar problem with powerpc + altivec vs. SPE:</span><br><span><<a href="https://github.com/randombit/botan/issues/1820">https://github.com/randombit/botan/issues/1820</a>></span><br><span></span><br><span>Which when you think about it might become obvious. The ahead-of-time</span><br><span>autodetection employed by botan does not really work when everything</span><br><span>is cross-compiled. But this has been the bane of OpenWrt and several</span><br><span>other Buildroot and non-buildroot projects from the beginning, so there</span><br><span>are ways to mitigate these problems efficiently.</span><br><span></span><br><span>Cheers,</span><br><span>Christian</span><br><span></span><br><span></span><br></div></blockquote></div></body></html>