Add /System/iOSSupport to the library search path on Mac Catalyst

[madsmtm]

On macOS, /System/iOSSupport contains iOS frameworks like UIKit, which is the whole idea of Mac Catalyst.

To link to these, we need to explicitly tell the linker about the support library stubs provided in the macOS SDK under the same path.

Concretely, when building a binary for Mac Catalyst, Xcode passes the following flags to the linker:

-iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/iOSSupport/System/Library/Frameworks
-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/iOSSupport/usr/lib

This is not something that can be disabled (it's enabled as soon as you enable SUPPORTS_MACCATALYST), so I think it's pretty safe to say that we don't need an option to turn these off.

I've chosen to slightly deviate from what Xcode does and use -F instead of -iframework, since we don't need to change the header search path, and this way the flags nicely match on all the linkers. From what I could tell by reading Clang sources, there shouldn't be a difference when just running the linker.

CC @BlackHoleFox, @shepmaster (I accidentally let rustbot choose the reviewer).

[rustbot]

r? @estebank

rustbot has assigned @estebank.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[BlackHoleFox]

I'm not opposed to this but it also seems less useful then the mirror for cc-rs. Users already need to define what framework you want the extern "C" block to link to. Is it to make that unneeded? Or is it just to match XCode better even if nothing in rustc or std actually needs this linkage?

[madsmtm]

Users already need to define what framework you want the extern "C" block to link to. Is it to make that unneeded? Or is it just to match XCode better even if nothing in rustc or std actually needs this linkage?

No, #[link(name = "UIKit", kind = "framework")] extern "C" {} would still be needed. The issue is that that doesn't work unless this option is present, i.e. the test I added in the second commit fails to link on Mac Catalyst targets.

(Even worse is when you link frameworks that are present on both platforms, like WebKit, since that ends up linking the macOS version of WebKit and not the iOS version).

I guess the user (or a library like objc2) could fix this by using cargo:rustc-link-arg=... in a build script, but that seems like a worse option than solving it in rustc itself.

[madsmtm]

r? shepmaster

[madsmtm]

Unsure who has macOS/Xcode experience that I could assign this to.

r? compiler

[Nadrieril]

Same

r? compiler

[thomcc]

I can confirm this makes sense to do for the catalyst targets.

[madsmtm]

Then since you're back from vacation, I'll assign you to the PR ;)
r? thomcc

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[wesleywiser]

Since @thomcc said this makes sense, I'm just going to

@bors r+

[bors]

📌 Commit ff3f0a3 has been approved by wesleywiser

It is now in the queue for this repository.

[bors]

⌛ Testing commit ff3f0a3 with merge 9782770...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 9782770 to master...

[rust-timer]

Finished benchmarking commit (9782770): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.2%, 0.3%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 676.092s -> 677.972s (0.28%)
Artifact size: 316.03 MiB -> 316.06 MiB (0.01%)

[petrochenkov]

@madsmtm
Clang supports Mac Catalyst targets, I assume, but I don't see the iOSSupport anywhere in its source code.
So it expects them to be passed from some higher build system layer (that's what "Xcode passes the following flags" I assume).
Why should rustc do differently and pass them by itself?

I'm currently auditing include directories passed to linkers and this is the only case in which rustc passes "system" directories, in other cases it leaves this work either to user or to cc/linker.

Also, is it correct that these directories go after user-passed directories, but before other "system" directories implicitly passed by cc/linker (the linker flag order affects search order)? Seems generally reasonable.

[bjorn3]

In the case of rust, most people expect that they can just run cargo build --target aarch64-apple-ios-macabi on a mac. When plain cargo is used, the only other location where the search path information could be encoded is cargo. Where possible target specific information is intentionally kept out of cargo and put in rustc instead. Cargo doesn't even know the file extension for executables, staticlibs and dylibs. It queries rustc for this information instead.