i think this is prefered, https://git.musl-libc.org/cgit/musl/commit/?id=d49cf07541bb54a5ac7aec1feec8514db33db8ea

i suppose this is for CCC? you could also use the release binaries which are statically linked against musl https://github.com/Disservin/fastchess/releases

Yes this if for CCC. Absolutely ancient system. gcc8.3, no clang, no perms, CentOS 8.
I can pitch using the static builds for CCC.

What is Fishtest using? I was intending to have OpenBench clients build from source, based on a commit/branch/tag ( If I ever get around to it ). And so I would think you would still want this fix to support older versions just in case?

fishtest is compiling from source so for the time being i'll add this..

recently added those static musl builds since i was thinking about moving away for self compiles on fishtest, my message on discord

been wondering about the way fastchess is used in fishtest and moving away from the fishtest compilation step..
and instead generate the binaries over github CI and downloading them..
a) would allow me to use newer c++ features and other libraries and better build setup
b) would help with compile bugs like #786 which some users experienced

musl requires linux kernel 2.6.39 which is from 2011 so a good base i think

I'll probably see whenever the jump from compiled -> binaries is made, and can adapt. I don't immediately know what code I would write generically on all platforms to identify the proper build, but someone will do that for me if I wait long enough for Fishtest.

I understand your position. If Fishtest + OpenBench were to use self-compiled builds for the next three years, you would be inundated with bug reports about obscure setups not building. That is annoying.

that and the other linked issue from above was actually a compiler bug happening on a specific ubuntu version together with arm which caused a miscompile.. and also cleaning up some parts of the code, like std::filesystem usage which is behind a bunch of flags to check if it is available on the system.. just more streamlined development overall

the proper build selection is just arch and os, im guessing something like this will work for 99% of users

import platform
import sys

def select_fastchess_asset():
    system = platform.system().lower()
    machine = platform.machine().lower()
    
    if machine in ('amd64', 'x86_64', 'x64'):
        arch = 'x86-64'
    elif machine in ('arm64', 'aarch64'):
        arch = 'arm64'
    elif machine in ('riscv64',):
        arch = 'risc-v'
    else:
        raise ValueError(f"Unsupported architecture: {machine}")
    
    if system == 'linux':
        return f"fastchess-linux-{arch}.tar"
    elif system == 'darwin':
        return f"fastchess-mac-{arch}.tar"
    elif system == 'windows':
        return f"fastchess-windows-{arch}.zip"
    else:
        raise ValueError(f"Unsupported OS: {system}")

Ah. That looks quite simple. In my mind, I was imagining the effort I did to discern ssse3/avx/avx2/avx512/vnni/sve/dotprod/yadayada.

But you presumably build these to the lowest common denominator.

yes 👍

i think this is prefered, https://git.musl-libc.org/cgit/musl/commit/?id=d49cf07541bb54a5ac7aec1feec8514db33db8ea

i suppose this is for CCC? you could also use the release binaries which are statically linked against musl https://github.com/Disservin/fastchess/releases

okay forget about this it looks like most people do it that way