CI: macOS build failures

[planetf1]

Currently macOS builds are failing

• Linux and MacOS tests
• Noted in PRs Create scorecard.yml (OpenSSF) #1708, Add MAYO signature scheme from NIST onramp #1707

These are failing with gcc on macOS 13 & macOS 14

For macOS 14 :

Component	Working	Failed
runner	2.316.1	2.316.1
Xcode	15.0.1	15.0.1
gcc	Apple 13.2.0	gcc 13.3.0
example log	https://github.com/open-quantum-safe/liboqs/actions/runs/9211032819/job/25339585288	https://github.com/open-quantum-safe/liboqs/actions/runs/9309161112/job/25624155404

For example

• macos-14, -DCMAKE_C_COMPILER=gcc-13 - reports the compiler as gcc 13.3.0 (13 hours ago)
• macos-14, -DCMAKE_C_COMPILER=gcc-13 - reports the compiler as gcc 13.2.0

The current runner software versions are documented here.

	Working	Failed
Date	2024-05-15	2024-05-29
Image Version	20240514.3	20240526.1
OS Version	13.6.6 (22G630)	13.6.7 (22G720)

[planetf1]

I've created a DRAFT PR as a TEST which replaces gcc with 13.2.0 to validate if this is the cause.

• macOS 13 gcc - SUCCESS

• macOS 14 gcc - SUCCESS

• wait for a fix to happen, somehow - but we don't know when

• debug - try and build with gcc 13.3.0 locally (a) homebrew b) local build), research open issues

• implement a similar workaround in short term (but must monitor and remove later)

Note that the test PR had a failure from circle CI on doxygen....

Thoughts @bhess @SWilson4 @baentsch ?

[planetf1]

Additional commit reverts the version reversion ...

• macOS 13 gcc - FAIL
• macOS 14 gcc - FAIL

This seems to prove the cause.

Also note that some annotations are added - just due to stderr when installing direct using ruby. Cosmetic, can be cleaned up if we want to go with a workaround

[macos (macos-14, -DOQS_USE_OPENSSL=OFF)](https://github.com/open-quantum-safe/liboqs/actions/runs/9317181419/job/25647067308#step:4:27)
Failed to load cask: [email protected] Cask 'gcc@13' is unreadable: wrong constant name #<Class:0x000000014973f790>

[SWilson4]

Thanks for looking into this, @planetf1. The doxygen error should be resolved by syncing your fork so that it includes commit a23046f.

I am OK with merging a workaround, as this does seem like a non-liboqs problem. However, I feel that we should leave this issue (or another one) open as a reminder to remove the workaround whenever possible.

[planetf1]

Thanks @SWilson4 thought I was up to date. pushed update now, so hopefully will be cleaner (except the annotations)

[planetf1]

My initial reason for doing this was to at least understand why the failure. Perhaps we could discuss in the dev call next week & decide if we want the workaround. If so we could use as-is (perhaps squash) or also cleanup the warnings (redirect!)

[bhess]

Thanks @planetf1 for investigating and adding the workaround!

[planetf1]

@bhess My current plan is to share the findings at the OQS status call so we can discuss/agree. However if there is critical mass of agreement we could merge ahead of time. Another option to consider is moving to a later gcc version.

[baentsch]

My current plan is to share the findings at the OQS status call so we can discuss/agree.

Sharing findings only at status calls is suboptimal for several reasons:

1. It slows down development
2. It robs non-participants of the option to check your findings
3. It eliminates the option for users to search github for "previously known issues" and learn from them

--> I'd strongly suggest always creating PRs that others can see and comment on. If they do not get merged, at least others (and posteriority) can see and learn; if they get merged, so much the better.

What I find troublesome is that these build failures did not get visible at top-level CI reporting (GH CI report not shown): Created #1827 to track.

[planetf1]

@baentsch very much agree with you on ensuring we always share info through the github issues for all of those reasons - the status call should only be in addition, and as a reminder to review the comment. Hopefully the text here, did address that.

Good catch on addressing the status reporting.