Summary: | dev-libs/nss-3.47.1-r1 - In file included from aes-armv8.c:16: /usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/9.2.0/include/arm_neon.h:31:2: error: #error "NEON intrinsics not available with the soft-float ABI. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gordon Bos <bugzilla> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | crabbedhaloablution, herrtimson, matoro_gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Gordon Bos
2020-01-04 18:46:34 UTC
(In reply to Gordon Bos from comment #0) > Actual Results: > Relevant portion of build log Please attach the entire build log to this bug report. there were quite a few changes regarding arm and neon code in recent months. you might want to try again with =nss-3.49, and possible use the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1608327 on top of that. I guess the guys at mozilla would be happy if someone tested that fix on softfloat, so go to that bug and post a comment if it either fixes your problem, or doesn't. Sorry. Forgot to report back. I had already fallen back on the schedule for a much needed new release and I decided to leave it at the 3.46 version that was already in the image. I did however test compiling the 3.48 version (with mspr-4.24) and that one did result in an installable binary. Being pressed for time I did not perform any further tests and discarded it as I really like to restrict myself to stable packages as much as possible for this project. I can only enourage you to try again with current nss-3.49.2, one hardfloat and one softfloat bug were fixed since the release of nss-3.49 and please report your bug upstream, there's a higher chance of getting stuff fixed that way. I ran into a variant of this bug today. But my situation was a little bit different. I was running on a 64 bit kernel (arm64), with a 64 bit userland, preparing a 32bit userland with chroot. Seems to me, nss has a cpuflags autodetecting component which always forces a march=armv8a. In my case with +crypto. Which made the build fail. It's not technically cross-compiling when doing it in chroot, but I think nss needs to be built into it's own native environment. Mostly because of cpu flags which are detected when building, instead of taken from make.conf. The same installation, mounted over nfs, on an official v7l 32 bit kernel, still in chroot, it built just fine. So, on 64 bit kernel, in chroot, nss didn't want to build. On 32 bit kernel, in chroot, it was just fine. |