Difficulties with macos-latest in build.yml

[simonjwright]

This is prompted by macOS failures in PR 1053.

I don’t understand why there should be macOS issues at all since the crate declares itself only available on Linux! but, if it was available on macOS, there would still be issues.

Both (MacPorts) / macos-latest and (alr dev) / macos-latest fail at the Set up devel alr step -- why does MacPorts need to do this?

I’d have expected the script to use alire-project/setup-alire@v3, not @v2.

The script runs-on macos-latest. Unfortunately, Github has silently updated macos-latest so it’s macos-14, i.e. aarch64!! The stable alr is an x86_64 build, which will run under Rosetta and look for and run an x86_64 compiler; if that succeeds, any resulting executable will also be x86_64, causing issues with any external crate that provides aarch64 libraries.

So, why did Set up devel alr fail while attempting to built alr?

The answer is here: this is the problem discussed here (solution already applied to the aarch64 GCC compiler available at GNAT FSF Builds, but not to the x86_64 compiler).

The default Xcode in macos-14 is v15.0.1. Sadly, so is the default in macos-13.
Possible fixes:

• select a version of Xcode which avoids the linking problem (14.2/3 for preference). I quite like the suggestions here.
• include the Xcode 15 fix in the x86_64 compiler.
• for macos-14, provide alr in aarch64 (see previous remarks about universal builds) so it picks the fixed compiler.
• run on macos-12.

[simonjwright]

Also, should we be using actions/checkout@v4?

[simonjwright]

Both (MacPorts) / macos-latest and (alr dev) / macos-latest fail at the Set up devel alr step -- why does MacPorts need to do this?

Yes. The PR wanted to merge into alire-project:stable-1.3.0, so why did this script section choose the devel- path?

    # By default, this sets up the newest indexed native toolchain
    - name: Set up stable `alr`
      if: contains(github.base_ref, 'stable-')
      uses: alire-project/setup-alire@v2

    # By default, this sets up the newest indexed native toolchain
    - name: Set up devel `alr`
      if: contains(github.base_ref, 'devel-')
      uses: alire-project/setup-alire@v2
      with:
        branch: 'master'

(BTW, the comments aren’t right - or, at least one of them isn’t!)

[mosteo]

I'm seeing several different issues that may be confusing the matters needlessly. I'm going to submit the plainest crate and we can work from there. Thanks for the proactiviness!

[mosteo]

A bit in more detail:

I don’t understand why there should be macOS issues at all since the crate declares itself only available on Linux! but, if it was available on macOS, there would still be issues.

By the time we know the crate is unavailable, we have already attempted building alr, is my guess without looking deeply into it.

Both (MacPorts) / macos-latest and (alr dev) / macos-latest fail at the Set up devel alr step -- why does MacPorts need to do this?

This was needed when MacPorts was only available in the devel version. I've removed it in alire-project/alire-index#1061

I’d have expected the script to use alire-project/setup-alire@v3, not @v2.

Yes, this is now updated, although there's no ill-effects on using v2, just the default alr changes.

So, why did Set up devel alr fail while attempting to built alr?

The answer is here: this is the problem discussed here (solution already applied to the aarch64 GCC compiler available at GNAT FSF Builds, but not to the x86_64 compiler).

Thanks for the digging. I think we can use macos-12 for now. I'm not sure if it's better to prepare universal macOS executables, or have both builds separately.

Also, should we be using actions/checkout@v4?

I'm not aware of changes/features that we need, so...

[mosteo]

Fixed in alire-project/alire-index#1061 by temporarily downgrading to macos-12.