Report underlying processor arch on Arm Macs

[jclarkeSTFC]

If someone with an Arm chip is running an x86_64 Mantid (currently the only type we make for MacOS), then it will run under the Rosetta translation layer. This means the OS architecture will be reported as x86_64. This bit of code is how Apple recommends to check if your code is running on Rosetta, which will then allow us to correctly determine how many Arm Mac users we have.

See here for the Apple docs. The example is in Objective-C but it's pretty similar in this case to C++.

Fixes #37592

Description of work

If running on an Apple machine, and the OS architecture is given as x86_64, then check if the code is running on Rosetta. If it is then change the osArch entry in the usage report to arm64_(x86_64). A native app will say the architecture is arm64 so I think it would be useful to distinguish between the two cases later (when we have a native version).

To test:

We don't want to actually send any usage reports, so e.g. comment out line 332 of UsageService.cpp

status = helper.sendRequest(url, responseStream);

Turn on usage reporting, put a breakpoint somewhere where you can see which OS architecture is going to get put into the osArch field of the usage report, e.g. in ConfigService.cpp::1013 getOSArchitecture. If you have an Arm Mac running a native build, then you should get arm64. If you have an Arm Mac and are running under Rosetta (you'll need a package build for this) then the string should be arm64_(x86_64). If you have an Intel Mac then it should be x86_64.

I think you can also check the OS string by running SegFault and checking the error report (usage reporting must be on still).

This does not require release notes because this does not change any user-facing behaviour.

---

Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

• Is the code of an acceptable quality?
• Does the code conform to the coding standards?
• Are the unit tests small and test the class in isolation?
• If there is GUI work does it follow the GUI standards?
• If there are changes in the release notes then do they describe the changes appropriately?
• Do the release notes conform to the release notes guide?

Functional Tests

• Do changes function as described? Add comments below that describe the tests performed?
• Do the changes handle unexpected situations, e.g. bad input?
• Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

[SilkeSchomann]

We need to back up the database of the usage reporter before merging this PR.

[cailafinn]

We want to make sure this works on a few different versions of macOS to ensure we're not breaking anything. Apple have a tendency to change the names of the sysctl commands between versions, so as a minimum we want this to be tested on:

• A new version of macOS (probably Sonoma) on an ARM machine. (New build server macs)
• An new version of macOS on an Intel machine (Mine or Silke's laptops)
• An old version of macOS (our old build servers (High Sierra))

[jclarkeSTFC]

The tests were run on isis-ndw2564mac, is that one of the new ones?

[cailafinn]

The tests were run on isis-ndw2564mac, is that one of the new ones?

Yes, that's one of the new ARM macs

[github-actions]

👋 Hi, @jclarkeSTFC,

Conflicts have been detected against the base branch. Please rebase your branch against the base branch.

[jclarkeSTFC]

There's also the Core laptop that's going to have an old OS on it, that laptop is maybe eight years old (for the third test option)

[SilkeSchomann]

I have followed the testing instructions and I can confirm that on my Intel macbook the OS architecture is reported as x86_64.

[sf1919]

Yes old MacBook that Core have would be a good 3rd option.

If @thomashampson can be Gatekeeper on this one that would be great. We need to ensure all 3 Mac versions have been tested before merging and we also need to ensure we have a backup of the database before merging takes place.

[cailafinn]

Tested cross-compiled on the arm-64 build server and it's coming back as being native (not translated). We know this can't be the case, so why this is happening is uncertain. For info, running the sysctl.proc_translated command in the IPython terminal when workbench has started reports as being translated.

[cailafinn]

Tried this again on both macOS High Sierra and a cross-compiled ARM version and both are working as expected. Checked version reported by error-reporter. Looks good to me now.