dispatch2 links to functions that are only available in macOS 10.14+ despite claiming support for 10.12+

[eggyal]

In particular (links to Apple documentation confirming requirement for 10.14+):

• dispatch_workloop_create_inactive
• dispatch_set_qos_class_floor
• dispatch_workloop_create

[eggyal]

Other parts of the Dispatch framework that Apple document as requiring a macOS > 10.12:

10.14+

• OS_dispatch_queue_concurrent
• OS_dispatch_queue_serial
• dispatch_async_and_wait
• dispatch_async_and_wait_f
• dispatch_barrier_async_and_wait
• dispatch_barrier_async_and_wait_f
• OS_dispatch_workloop
• dispatch_workloop_set_autorelease_frequency
• DISPATCH_WALLTIME_NOW

14.0+

• OS_dispatch_queue_serial_executor

14.4+

• dispatch_allow_send_signals

[madsmtm]

A bunch of the crates in this repo wraps functions that are only available on newer OSes, and then relies on the wrappers being dead-stripped before the linker attempts to look up the symbols. I suspect that the Xcode 8/9 linker works a bit differently, it tries to find the symbols before dead-stripping.

This is admittedly a bit brittle, but I'd really like to avoid having to add a bunch of Cargo feature flags like [features] macos_10_13 = [] macos_10_14 = [] etc.

Interestingly, the same is done for dispatch_async_and_wait, it's wrapped as DispatchQueue::exec_sync_and_wait_with_block, but that doesn't give an error - perhaps it's enough to simply add #[inline] to our wrappers, that seems to make Rust not codegen the wrappers if they're not actually used anywhere.

[eggyal]

So if one actually uses those APIs and builds for a 10.12 target, the result will be a broken binary? Unless one gets hold of and uses the 10.12 SDK (which I believe is Apple's recommendation), in which case one at least will get a linker error?

Feel like we should be able to auto-generate an attribute proc macro eg #[macos(10.14..)], #[macos(10.12..=12.6)], etc — which could then expand to conditional compilation directives; and then user could specify eg --cfg macos=10.12 rather than cargo feature flags if preferable?

[madsmtm]

So if one actually uses those APIs and builds for a 10.12 target, the result will be a broken binary? Unless one gets hold of and uses the 10.12 SDK (which I believe is Apple's recommendation), in which case one at least will get a linker error?

Yes. Where have you seen the recommendation to build for older platforms with an older SDK? From what I've seen, they tend to recommend that you use the newest Xcode and SDK.

Feel like we should be able to auto-generate an attribute proc macro eg #[macos(10.14..)], #[macos(10.12..=12.6)], etc — which could then expand to conditional compilation directives; and then user could specify eg --cfg macos=10.12 rather than cargo feature flags if preferable?

Not a bad idea to use raw feature flags, though in the general case that would expand to a lot of cfgs (e.g. if I enable --cfg macos=10.14, I'd probably want everything from macos=10.12 enabled too).

My ideal solution to all this would be:

1. Weakly import the symbol instead, Tracking issue for the linkage feature rust-lang/rust#29603. As a workaround, we could probably expose wrappers around dlsym (this would also allow using older SDKs where the symbol isn't available).
2. Some way to avoid ^ and instead statically link when the version is known to be high enough, see RFC: cfg_target_version rust-lang/rfcs#3750.
3. Some way to make rustc emit the required libSystem.tbd to allow linking regardless of installed SDK, see Implement raw-dylib on Mach-O rust-lang/rust#146357.

See also #266 for tracking of this issue in general.

[eggyal]

Yes. Where have you seen the recommendation to build for older platforms with an older SDK?

Nothing official, but I've seen for example https://stackoverflow.com/questions/11684302/mac-sdk-using-latest-sdk-but-ensuring-backwards-compatibility-with-earlier-depl#11723461 and https://developer.apple.com/forums/thread/676792?answerId=668064022#668064022.

Not a bad idea to use raw feature flags, though in the general case that would expand to a lot of cfgs

Apologies if my idea was unclear. I meant during the proc macro expansion, it could emit #[cfg(false)] (or just outright remove the annotated item from the output tokenstream) if the provided target --cfg macos= version isn't within the #[macos(..)] range of the item's annotation.

[madsmtm]

Apologies if my idea was unclear. I meant during the proc macro expansion, it could emit #[cfg(false)] (or just outright remove the annotated item from the output tokenstream) if the provided target --cfg macos= version isn't within the #[macos(..)] range of the item's annotation.

Ah, that makes more sense.

I try to avoid proc macros in this project for compile times though :/

[madsmtm]

I fixed this in e429f0a by inlining the wrappers, let's use #266 for tracking doing this in a better way.