[DO NOT SUBMIT] Try new native MAC build computers

[HannesWell]

Relates to

• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6621#note_6796846

See also:

• [DO NOT SUBMIT] Experiments with Mac compile target #2610

[github-actions]

Test Results (macos)

   54 files  ±0     54 suites  ±0   8m 34s ⏱️ -19s
4 531 tests ±0  4 287 ✅ ±0  244 💤 ±0  0 ❌ ±0 
2 130 runs  ±0  2 068 ✅ ±0   62 💤 ±0  0 ❌ ±0 

Results for commit ea10332. ± Comparison against base commit 98062b7.

♻️ This comment has been updated with latest results.

[HannesWell]

@HeikoKlare and @Phillipus could you check the new binaries? Especially with respect to the minimally required version of mac to use them, like in

• [DO NOT SUBMIT] Experiments with Mac compile target #2610

[Phillipus]

could you check the new binaries?

I can if you can tell me how/where. :-)

[HeikoKlare]

I get the following information for the built binaries from vtool comparing the current master state binaries and the ones from the experimental build on new hardware https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-3175/5/ :

x64

New:

Load command 7
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.10
      sdk 15.5
Load command 8
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

Existing:

Load command 7
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.10
      sdk 12.1
Load command 8
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

aarch64

New:

Load command 8
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 26.4
   ntools 1
     tool LD
  version 1266.8
Load command 9
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

Existing:

Load command 8
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 13.0
   ntools 1
     tool LD
  version 820.1
Load command 9
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

I tested both of them on an aarch64 MacBook:

ProductName:		macOS
ProductVersion:		26.3.1
BuildVersion:		25D2128

To do so, I added the binaries generated in https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-3175/5/ to the fragments in my workspace with SWT master state. I adapted the platform filter of the x64 fragment to make it usable on aarch64 architecture. I then started SDK products with either of the fragments and a matching JRE (x64 and aarch64). Both work fine in the sense that an SDK starts without any unexpected errors.

[Phillipus]

I took the *.jnilib binary files from here and renamed them to 4973r7 and replaced the current ones and ran my RCP app on an old Intel MacBook running macOS 13 (Ventura)...

...and it all seems OK.

[HannesWell]

I get the following information for the built binaries from vtool comparing the current master state binaries and the ones from the experimental build on new hardware

I updated #2610 to use the exact same build configuration as this one with the only exception that that PR uses the old agents (enforced) and this one uses the new ones and I get similar results from vtool -show.
Everything except for the SDK seems to be the same, which is expected and should not alter the behavior.

Both work fine in the sense that an SDK starts without any unexpected errors.

ran my RCP app on an old Intel MacBook running macOS 13 (Ventura)...

...and it all seems OK.

Thanks you both for checking. So with respect to the building the binaries, the hardware update seems to be fine.