LIT tests fail on macOS version mismatch due to linker warning breaking CHECK-NEXT directives

[sengthai]

Context
When using a Catalyst build from an older macOS version on a newer macOS, or vice versa, the test suite fails due to a linker warning being injected into the output stream:
ld: warning: object file (/private/var/folders/m4/asd321/T/lit-t/circuit/circuit.o) was built for newer 'macOS' version (26.0) than being linked (15.5)
This warning breaks tests that use CHECK-NEXT directives, which strictly verify that output appears on consecutive lines. The unexpected warning line causes a mismatch.

Steps to Reproduce

• Build Catalyst on macOS version X
• Run the test suite on macOS version Y (where X ≠ Y)
• Observe test failures due to the linker warning breaking CHECK-NEXT checks

Expected Behavior
Tests should pass regardless of minor macOS version differences, as the linker warning does not affect functionality.
Proposed Solution
Relax the strict CHECK-NEXT directives to CHECK where appropriate. This allows intermediate lines (like system warnings) to appear without breaking the test assertions.
For example, change:
# CHECK-NEXT: [DIAGNOSTICS] Running capture
to:
# CHECK: [DIAGNOSTICS] Running capture

Actually Behavior

.
.
.
ld: warning: object file (/private/var/folders/m4/hymm68011xs1pk3zqv3bb2yc0000gr/T/lit-tmp-vj80pa5a/circuitb1whf74a/circuit.o) was built for newer 'macOS' version (26.0) than being linked (15.5)
^

Input file: <stdin>
Check file: catalyst/frontend/test/lit/test_instrumentation_console.py

-dump-input=help explains the following input dump.

Input was:
<<<<<<
         1: [DIAGNOSTICS] Running pre_compilation walltime: 0.007 ms cputime: 0.005 ms  
         2: [DIAGNOSTICS] Running capture walltime: 146.097 ms cputime: 112.563 ms programsize: 47 lines 
         3: [DIAGNOSTICS] Running generate_ir walltime: 47.462 ms cputime: 32.68 ms programsize: 49 lines 
         4: ld: warning: object file (/private/var/folders/m4/hymm68011xs1pk3zqv3bb2yc0000gr/T/lit-tmp-vj80pa5a/circuitb1whf74a/circuit.o) was built for newer 'macOS' version (26.0) than being linked (15.5) 
         5: [DIAGNOSTICS] Running compile walltime: 1018.729 ms cputime: 43.132 ms programsize: 129 lines 
next:51     !~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                  error: match on wrong line
         6: [DIAGNOSTICS] Running run walltime: 52.037 ms cputime: 38.046 ms  
         7: [DIAGNOSTICS] > Total pre_compilation walltime: 0.015 ms cputime: 0.012 ms  
         8: [DIAGNOSTICS] > Total capture walltime: 34.807 ms cputime: 31.292 ms programsize: 47 lines 
         9: [DIAGNOSTICS] > Total generate_ir walltime: 5.791 ms cputime: 5.244 ms programsize: 49 lines 
        10: ld: warning: object file (/private/var/folders/m4/hymm68011xs1pk3zqv3bb2yc0000gr/T/lit-tmp-vj80pa5a/circuitqnb9fw2u/circuit.o) was built for newer 'macOS' version (26.0) than being linked (15.5) 
         .
         .
         .
>>>>>>```

[dime10]

I actually investigated a similar issue last week, but yours might be somewhat different. The issue we've had before was that even though nothing about the system or environment changes, the user program (e.g. circuit.o) was being compiled for an older version than the catalyst libraries (e.g. librt_capi.dylib).
The cause for that issue is that the libraries are built with CMake, while the user program is compiled directly via LLVM/Clang. In the absence of an explicit flag for the OSX deployment target, the defaults determined by CMake vs Clang are different, resulting in a warning like:

ld: warning: building for macOS-15.0, but linking with dylib '@rpath/librt_capi.dylib' which was built for newer version 15.7

This is something we could probably address, but I found out CMake got rid of this behaviour in version 4 and the warning goes away when upgrading to >=4.

If you're still using an older version of CMake, I would recommend trying to upgrade first.
However, there is a difference in your issue, since you actually did upgrade your OS between compiling Catalyst and running it. So a second test would be to check whether recompiling the Catalyst libraries on the new system fixes it.

Tests should pass regardless of minor macOS version differences, as the linker warning does not affect functionality.

The versions you are reporting do not just differ in minor version actually, but in the major version number: (26.0) vs (15.5)

I also wouldn't want us to just ignore this warning even if it is harmless, because I wouldn't want users to have to deal with it. If the released version of Catalyst has this issue, we definitely need to look into it. But I know we set the deployment target explicitly when building our wheels, so I hope the issue is not present there.