Github messages for voidlinux
 help / color / mirror / Atom feed
From: CtrlC-Root <CtrlC-Root@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: Direwolf on Rpi Zero W fails to run due to missing NEON support.
Date: Sat, 20 Jan 2024 21:38:49 +0100	[thread overview]
Message-ID: <20240120203849.9B36021551@inbox.vuxu.org> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-48299@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 4121 bytes --]

New comment by CtrlC-Root on void-packages repository

https://github.com/void-linux/void-packages/issues/48299#issuecomment-1902260166

Comment:
Thank you for getting to this so quickly! Unfortunately I don't believe this fixes the issue. I installed the updated package and I still see the same error as before and I still see the `NEONv1` flag in the binary `readelf` output. I looked at your commit and the build scripts for `direwolf` and I think I understand why. If you look at the section of the `FindCPUflags.cmake` file you are editing with `vsed` you'll see that while `HAS_NEON` is now forced to `OFF` it's still configuring the preprocessor and compiler to use NEON: https://github.com/wb2osz/direwolf/blob/master/cmake/modules/FindCPUflags.cmake#L366-L370.

I can confirm that this is the issue though because my source build on the Raspberry Pi Zero finally finished and that one works correctly. I can no longer see the NEON flag in the `readelf` output:

```
[alex@digirig void-packages]$ readelf -A /usr/bin/direwolf 
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
```

I spent quite a bit of time trying to find a `sed` command to fix this but ultimately gave up. Is there a way to conditionally apply a patch to a package based on the architecture? If so this should do the trick:

```
[... ]$ cat srcpkgs/direwolf/patches/disable_arm_neon.patch
disable ARM NEON instructions

--- a/cmake/modules/FindCPUflags.cmake
+++ b/cmake/modules/FindCPUflags.cmake
@@ -350,27 +350,7 @@ else ()
        set(HAS_AVX512 OFF CACHE BOOL "Architecture does not have AVX512 SIMD enabled")
     endif()
 elseif(ARCHITECTURE_ARM)
-    if(C_MSVC)
-        try_run(RUN_NEON COMPILE_NEON "${CMAKE_BINARY_DIR}/tmp" "${TEST_DIR}/test_arm_neon.cxx" COMPILE_DEFINITIONS /O0)
-    else()
-        if(${CMAKE_HOST_SYSTEM_PROCESSOR} STREQUAL ${CMAKE_SYSTEM_PROCESSOR})
-          try_run(RUN_NEON COMPILE_NEON "${CMAKE_BINARY_DIR}/tmp" "${TEST_DIR}/test_arm_neon.cxx" COMPILE_DEFINITIONS -mfpu=neon -O0)
-        else()  
-          try_compile(COMPILE_NEON "${CMAKE_BINARY_DIR}/tmp" "${TEST_DIR}/test_arm_neon.cxx" COMPILE_DEFINITIONS -mfpu=neon -O0)
-          set(RUN_NEON  0)
-        endif()
-    endif()
-    if(COMPILE_NEON AND RUN_NEON EQUAL 0)
-       set(HAS_NEON ON CACHE BOOL "Architecture has NEON SIMD enabled")
-       message(STATUS "Use NEON SIMD instructions")
-       if(C_GCC OR C_CLANG)
-           set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mfpu=neon" )
-           set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mfpu=neon" )
-           add_definitions(-DUSE_NEON)
-       endif()
-    else()
-       set(HAS_NEON OFF CACHE BOOL "Architecture does not have NEON SIMD enabled")
-    endif()
+   set(HAS_NEON OFF CACHE BOOL "Architecture does not have NEON SIMD enabled")
 elseif(ARCHITECTURE_ARM64)
     # Advanced SIMD (aka NEON) is mandatory for AArch64
     set(HAS_NEON ON CACHE BOOL "Architecture has NEON SIMD enabled")
```

Cross compiling with the patch above using `./xbps-src -a armv6l build direwolf` I see that NEON has been disabled:

```
[... ]$ readelf -A masterdir/builddir/direwolf-1.7/build/src/direwolf
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
```

  parent reply	other threads:[~2024-01-20 20:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-20 15:03 [ISSUE] " CtrlC-Root
2024-01-20 16:39 ` classabbyamp
2024-01-20 16:39 ` [ISSUE] [CLOSED] " classabbyamp
2024-01-20 20:38 ` CtrlC-Root [this message]
2024-01-21 20:18 ` classabbyamp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240120203849.9B36021551@inbox.vuxu.org \
    --to=ctrlc-root@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).