Arch Linux User Repository

@apetresc Thank you for correcting me; So if the package version changes would the PKGBUILD also be changed unless stated otherwise?

@Peter2469 Not exactly; if Stockfish 15 comes out then the package version changes, and pkgrel goes back down to 1. pkgrel is meant to increment for non-upstream changes within a release (for things like fixing PKGBUILDs).

@bulletmark, That is true I would assume if pkgrel gets bumped it is if Stockfish 15 comes out?

@Peter2469, yes I know there would be others. To be clear, I didn't bump the pkgrel because there is no point forcing all existing users to see an update (e.g via yay) when none of them are aarch64 users. This change only affects new aarch64 users, who are yet to install it.

@bulletmark, I have tested it and can confirm that it works fine; there would be many other people like me with the pinephone or devices with the same architecture so adding the option may be an idea but understandable at this current circumstance.

@Peter2469, I added that change and I'll have to trust it works. Did not change the pkgrel because only affects you. Please confirm ok.

Hello, I edited the PKGBUILD to add support to aarch64 which my pinephone uses. I tried to do armv8-a which is the microarchitecture but it didn't want to build.

The arch would support "aarch64" and you just need to add 2 lines

elif [[ "$CARCH" == "aarch64" ]]; then
    _arch=armv8

Thank you @bulletmark, that does seem to work. Successfully ran

./stockfish bench 16 1 13 default depth mixed

@setone, yes that check is primitive and my fix here is primitive as well but should work. Can you please try it: http://ix.io/3tdC

Hello, I have an older AMD processor:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         40 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               AuthenticAMD
  Model name:            AMD A8-3820 APU with Radeon(tm) HD Graphics
    CPU family:          18
    Model:               1
    Thread(s) per core:  1
    Core(s) per socket:  4
    Socket(s):           1
    Stepping:            0
    Frequency boost:     enabled
    CPU max MHz:         2500.0000
    CPU min MHz:         800.0000
    BogoMIPS:            5002.60
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_api
                         cid pni cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall arat npt lbrv svm_lock nrip_save pausefilter
Virtualization features: 
  Virtualization:        AMD-V
Caches (sum of all):     
  L1d:                   256 KiB (4 instances)
  L1i:                   256 KiB (4 instances)
  L2:                    4 MiB (4 instances)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-3
Vulnerabilities:         
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Spec store bypass:     Not affected
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Full AMD retpoline, STIBP disabled, RSB filling
  Srbds:                 Not affected
  Tsx async abort:       Not affected

When I build using makepkg, PKGBUILD incorrectly identifies my architecture as x86-64-modern. This causes stockfish to crash in smmintrin.h:

281│ extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__))
282│ _mm_max_epi8 (__m128i __X, __m128i __Y)
283│ {
284├─> return (__m128i) __builtin_ia32_pmaxsb128 ((__v16qi)__X, (__v16qi)__Y);
285│ }

I can work around the problem by commenting out 2 lines in PKGBUILD:

 30 #  elif grep -q popcnt /proc/cpuinfo; then
 31 #    _arch=x86-64-modern

which causes my architecture to be correctly identified as x86-64. So there seems to be an issue with the test.