Not sure which one of two commands is causing the lower overhead, but shouldn't you just build Wine using the 10.11 SDK if you plan to deploy it on 10.11? This could theoretically also apply to other parts of Wine and I don't think it makes sense to add backwards compatibility hacks everywhere.
Regards, Michael
On Jun 1, 2017, at 3:19 PM, Michael Müller michael@fds-team.de wrote:
Not sure which one of two commands is causing the lower overhead, but shouldn't you just build Wine using the 10.11 SDK if you plan to deploy it on 10.11?
No. That's not the way Mac software is typically built. The whole point of a deployment target[1] is that it's often different from the SDK against which you're building. You typically build against the newest SDK. (Apple used to ship a few old SDKs with each version of Xcode but stopped doing that and encourages everyone to use the latest.)
[1] https://developer.apple.com/library/content/documentation/DeveloperTools/Con...
Ideally, the code would check for the run-time availability of clock_gettime() and use it when it's available (assuming a build against the 10.12 SDK) and fall back to mach_absolute_time() otherwise. Alexandre expressed a preference for the approach in my patch, instead.
This could theoretically also apply to other parts of Wine and I don't think it makes sense to add backwards compatibility hacks everywhere.
Theoretically, it could. In practice, it's not been a big problem.
-Ken
-
Ken Thomases -
Michael Müller