The release workflow's comments describe flags the jobs do not pass, which makes it impossible to tell from reading whether the shipped artifacts are what the comment claims.
Where
.github/workflows/release.yml, the linux-arm64 job:
# GEMM_PROVIDER=native -> native NEON fp32 + vendored FFT (no OpenBLAS/FFTW).
# EXTRA_LDFLAGS "-static -s": fully static + strip symbols at link time.
The build step below it is:
make TARGET=linux CC=gcc GEMM_PROVIDER=native lib
No EXTRA_LDFLAGS anywhere. The -static -s line is left over from when this job built an executable; the release ships libgeist.a plus headers, and static-linking flags do not apply to an archive.
Reproduce
grep -n "EXTRA_LDFLAGS" .github/workflows/release.yml # comment only, never a flag
Done when
The comment describes what the job does. If any part of -static -s still has meaning for the packaged SDK, say which and why; if not, delete the sentence. Check the linux-x86_64 and macos-arm64 jobs for the same drift while you are in there.
Small and self-contained, but it touches the file that decides what users download — read the whole job before editing.
The release workflow's comments describe flags the jobs do not pass, which makes it impossible to tell from reading whether the shipped artifacts are what the comment claims.
Where
.github/workflows/release.yml, thelinux-arm64job:The build step below it is:
make TARGET=linux CC=gcc GEMM_PROVIDER=native libNo
EXTRA_LDFLAGSanywhere. The-static -sline is left over from when this job built an executable; the release shipslibgeist.aplus headers, and static-linking flags do not apply to an archive.Reproduce
Done when
The comment describes what the job does. If any part of
-static -sstill has meaning for the packaged SDK, say which and why; if not, delete the sentence. Check thelinux-x86_64andmacos-arm64jobs for the same drift while you are in there.Small and self-contained, but it touches the file that decides what users download — read the whole job before editing.