[ebuild R ] net-misc/freerdp-2.0.0_rc4:0/2::gentoo USE="X alsa client cups doc gstreamer jpeg usb xv -debug -ffmpeg -libav -libressl -openh264 -pulseaudio -server -smartcard -systemd -test -wayland -xinerama (-neon%)" CPU_FLAGS_ARM="(-neon)" 0 KiB The build system tries to use -mfpu=neon which arm64 does not support. Reproducible: Always Steps to Reproduce: 1.emerge -1 net-misc/freerdp 2. 3. Actual Results: Build fails due to -mfpu=neon Expected Results: net-misc/freerdp-2.0.0_rc4 merges successfully Build log will be attached soon.
Created attachment 591222 [details] build.log Build log as indicated
profiles/arch/arm64/package.use.mask has this: # Alexis Ballier <aballier@gentoo.org> (2017-07-14) # Appends -mfpu=neon and asm seems arm32 net-misc/freerdp cpu_flags_arm_neon But your build log shows cpu_flags_arm_neon in USE, and -DWITH_NEON=yes being passed to to cmake. Have you unmasked the USE flag somehow?
On this Cavium Thunder II box, cpuid2cpuflags-8 says arm64-build / # cpuid2cpuflags CPU_FLAGS_ARM: edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 aes sha1 sha2 crc32 v4 v5 v6 v7 v8 thumb2 So I put that in make.conf. Its arm64 only. On arm64, the 32 bit instruction set is optional. This box does not have it. Commenting out CPU_FLAGS_ARM allows net-misc/freerdp to build, so that's got to the bottom of thin bug. In all the time I've been using CPU_FLAGS_ARM as indicated by cpuid2cpuflags, this is the first build failure I've hit. I'll raise a new bug against cpuid2cpuflags-8 after I've tried the build an a system that does have both the 64 bit and 32 bit instruction sets.
(In reply to Roy Bamford from comment #3) The package.use.mask setting should trump anything you have in make.conf, so I'm still curious how this seems to have failed.
I guess cpu_flags_arm_neon was unmasked between the ebuild update https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3672f2be8e5d8b8cfa1054a5cc0b416fedb6184a and the profiles update https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5db27b75d3c3cf1daf70f45baecc65b54c9865f8
Something has changed. The original emerge -1av net-misc/freerdp output was ... [ebuild R ] net-misc/freerdp-2.0.0_rc4:0/2::gentoo USE="X alsa client cups doc gstreamer jpeg usb xv -debug -ffmpeg -libav -libressl -openh264 -pulseaudio -server -smartcard -systemd -test -wayland -xinerama (-neon%)" CPU_FLAGS_ARM="(-neon)" 0 KiB Note the new USE (-neon%) and CPU_FLAGS_ARM="(-neon)" They both mean the same thing. A few minutes ago it gave ebuild R ] net-misc/freerdp-2.0.0_rc4:0/2::gentoo USE="X alsa client cups doc gstreamer jpeg usb xv -debug -ffmpeg -libav -libressl -openh264 -pulseaudio -server -smartcard -systemd -test -wayland -xinerama" CPU_FLAGS_ARM="(-neon)" 0 KiB. The USE=(-neon%) is gone. That built too. The ::gentoo repo is at Timestamp of repository gentoo: Sun, 29 Sep 2019 07:15:01 +0000 Head commit of repository gentoo: 48e774a623293874352afd3036974bcadde487b8 The 64 bit Raspberry Pi4, the CPU with both instruction sets, has the tip of its git repo at commit 48e774a623293874352afd3036974bcadde487b8 (origin/master, origin/HEAD) Date: Sat Sep 28 21:14:45 2019 -0700 Its pure luck they are in the same place, as the Pi uses git anh the Cavium Thunder uses rsync. The build succeeded on the Pi. Back to the Cavium, the last --sync was 1569742696: Started emerge on: Sep 29, 2019 08:38:15 1569742696: *** emerge --sync 1569742696: === sync 1569742696: >>> Syncing repository 'gentoo' into '/usr/portage'... 1569742700: >>> Starting rsync with rsync://[2607:f128:1:3::2]/gentoo-portage 1569742866: === Sync completed for gentoo 1569742868: *** terminating. ... Failed 1569751235: Started emerge on: Sep 29, 2019 11:00:35 1569751235: *** emerge --oneshot --ask --verbose net-misc/freerdp 1569751460: *** exiting unsuccessfully with status '130'. 1569751460: *** terminating. ... Worked with CPU_FLAGS_ARM 1569842132: Started emerge on: Sep 30, 2019 12:15:32 1569842132: *** emerge --oneshot --ask --verbose net-misc/freerdp 1569842277: >>> emerge (1 of 1) net-misc/freerdp-2.0.0_rc4 to / 1569842277: === (1 of 1) Cleaning (net-misc/freerdp-2.0.0_rc4::/usr/portage/net-misc/freerdp/freerdp-2.0.0_rc4.ebuild) 1569842279: === (1 of 1) Compiling/Packaging (net-misc/freerdp-2.0.0_rc4::/usr/portage/net-misc/freerdp/freerdp-2.0.0_rc4.ebuild) 1569842639: === (1 of 1) Merging (net-misc/freerdp-2.0.0_rc4::/usr/portage/net-misc/freerdp/freerdp-2.0.0_rc4.ebuild) 1569842654: >>> AUTOCLEAN: net-misc/freerdp:0 1569842654: === Unmerging... (net-misc/freerdp-2.0.0_rc4) 1569842665: >>> unmerge success: net-misc/freerdp-2.0.0_rc4 ... Worked with CPU_FLAGS_ARM reinstated. 1569872250: Started emerge on: Sep 30, 2019 20:37:29 1569872250: *** emerge --oneshot --ask --verbose net-misc/freerdp 1569872439: >>> emerge (1 of 1) net-misc/freerdp-2.0.0_rc4 to / 1569872439: === (1 of 1) Cleaning (net-misc/freerdp-2.0.0_rc4::/usr/portage/net-misc/freerdp/freerdp-2.0.0_rc4.ebuild) 1569872440: === (1 of 1) Compiling/Packaging (net-misc/freerdp-2.0.0_rc4::/usr/portage/net-misc/freerdp/freerdp-2.0.0_rc4.ebuild) 1569872779: === (1 of 1) Merging (net-misc/freerdp-2.0.0_rc4::/usr/portage/net-misc/freerdp/freerdp-2.0.0_rc4.ebuild) 1569872793: >>> AUTOCLEAN: net-misc/freerdp:0 1569872793: === Unmerging... (net-misc/freerdp-2.0.0_rc4) My /etc/portage/* is at http://bloodnoc.org/~roy/Pi3_64bit/etc_portage_arm64/ Its kept there to go with the binhost at http://bloodnoc.org/~roy/BINHOSTS/ in case anyone wants to recreate the arm64 install I have on my Pi3 and Pi4. It looks like there has been an emerge --sync but its not in emerge.log
