Closed tersec closed 4 months ago
I have found out that the Clang versions on our MacOS hosts are not consistent:
> ansible ci-slave-macos -o -a 'sudo -iu jenkins /opt/homebrew/opt/llvm/bin/clang --version | head -n1'
maci7-01.ms-eu-dublin.ci.devel | CHANGED | rc=0 | (stdout) Homebrew clang version 18.1.4
maci7-02.ms-eu-dublin.ci.devel | CHANGED | rc=0 | (stdout) Homebrew clang version 18.1.4
maci7-03.ms-eu-dublin.ci.devel | CHANGED | rc=0 | (stdout) Homebrew clang version 17.0.6
macm1-01.ih-eu-mda1.ci.devel | CHANGED | rc=0 | (stdout) Homebrew clang version 17.0.6
macm2-01.ih-eu-mda1.ci.devel | CHANGED | rc=0 | (stdout) Homebrew clang version 18.1.4
macm2-01.ih-eu-mda1.ci.release | CHANGED | rc=0 | (stdout) Homebrew clang version 18.1.4
macm2-02.ih-eu-mda1.ci.devel | CHANGED | rc=0 | (stdout) Homebrew clang version 17.0.6
Even though we do pin it as llvm@18
in our Ansible config:
https://github.com/status-im/infra-ci/blob/fc984e12/ansible/group_vars/ci-slave-macos.yml#L32
I have fixed it so it should be correct now. But maybe we should enforce some kind of check on LLVM version?
Or simply use Nix shell to pin it more effectively.
Appears to work with Clang 18:
Appears to work with Clang 18:
oh if it works with clang 18 just make them all clang 18 and we can be done with it.
don't really want to spend time hunting more clang bugs if they're already fixed in current version
clang 18 does appear to address this, not pursuing any more