CMake: properly fix build on macOS with Ninja (cf. to response files)

[chris-se]

On macOS several build-related programs (cc, ar) will not accept the linker line if too many files have been added to it in the DYNAMIC_ARCH case. (This now occurs on all platforms where macOS runs / used to run, as there are enough ARM variants that are build with DYNAMIC_ARCH that the number of files exceeds the intrinsic limit on macOS.)

The workaround for this is to use response files that contain the file list themselves, and pass these to the build system. For dynamic libraries this works fine, but for static libraries it doesn't because ar doesn't accept response files on macOS. For this reason there was previously a workaround in CMakeLists.txt to handle this, but the workaround didn't take into consideration that when building only a shared library it is not actually necessary, and when building static libraries the response file CMake generates for Ninja is at a different location than the response files CMake generates for Unix Makefiles.

This commit cleans this all up by setting the necessary options for the response files to be properly generated, and adjusts the additional workaround to only be applicable in the case a static library is built. The workaround is also adjusted to handle the Ninja case.

Fixes GitHub issue #5775

[martin-frbg]

Thanks. Perhaps it would (also) make sense to drop a few targets when building for macOS - neither Fugaku nor any of the ThunderX chips seem particularly likely to be present in an iAnything, and even the Neoverse lineup feels questionable in that context.

[codspeed-hq]

Merging this PR will not alter performance

✅ 62 untouched benchmarks

---

_{Comparing chris-se:cmake-macos-ninja (ca4d867) with develop (3c553ef)}

[chris-se]

That would probably also make sense, if you wish I can provide another pull request for this. I suggest doing this separately though. Unfortunately I don't 100% know the nomenclature of OpenBLAS (i.e. how the names OpenBLAS uses translate to different chips). With the most current XCode OpenBLAS wants to generate the following variants:

• A64FX
• ARMV8
• ARMV8SVE
• ARMV9SME
• CORTEXA53
• CORTEXA57
• EMAG8180
• NEOVERSEN1
• NEOVERSEN2
• NEOVERSEV1
• THUNDERX
• THUNDERX2T99
• THUNDERX3T110
• TSV110
• VORTEXM4

If you tell me which ones of these are relevant to macOS/arm64 (which will only run on Apple's own silicon, i.e. A18 Pro, M1, M2, M3, M4, M5, ...) I'd be happy to provide another pull request that restricts this on macOS platforms.

[martin-frbg]

I'm not that familiar with Apple's product range, but I suspect the only actually relevant targets would be CortexA57 (and perhaps A53 too ?) for very old models of iPhone (might make sense to look up what SoC the first generation had) - or just the baseline ARMV8 for them. Next perhaps NeoverseN1 as a stand-in for the Vortex target (M1 to M3), and VortexM4 for the current top of the line with SME but no SVE, perhaps ARMV9SME for any future chip that might support non-streaming SVE.

[martin-frbg]

Can probably skip the A53/A57 combo as too little seems to be known about the internals of A8..A10, and autodetection would only resolve to ARMV8.
For A11 and beyond, it might actually make sense to use NEOVERSEN1 (just based on instruction set) if anybody has the hardware - again these currently would be autodetected as ARMV8, as their cpu part ids are not known to the autodetection code in dynamic_arm64.c

So in effect, the DYNAMIC_ARCH list would shrink to ARMV8 NEOVERSEN1 VORTEXM4 ARMV9SME - of course this is
already doable by supplying your own DYNAMIC_LIST. Similarly, the defaults for x86_64 include a host of AMD chips and cpus that came out after Apple's switch to the ARM architecture - both at least officially supported by Apple

[chris-se]

I wouldn't necessarily touch the x86_64 list because some people may be running Hackintoshes on these more modern CPUs. But I haven't seen the arm64 version of macOS running on anything other than Apple silicon, so I'll restrict it there to the ones you mentioned here - many thanks for the list.

I'll create another pull request either today or on Monday, after I've tested this.