what say we just use MacOSX.sdk preferentially on BigSur and up?
jmr at macports.org
Fri Dec 18 17:44:49 UTC 2020
On 2020-12-19 03:58 , Ken Cunningham wrote:
> That will save a lot of heartburn with all the gcc ports, python, perl,
> and all the others that bake in a path to the SDK.
> And it's how Apple is going now anyway.
> And helps ports build when they need a newer SDK than the versioned one
> that matches their system.
> This was undesirable in the 10.4 to 10.13 era, but it may be time to do
> it now for 11.x and up.
> and https://trac.macports.org/ticket/61866
> and no doubt many more similar headaches to come…
The situation hasn't fundamentally changed; the majority of projects
still don't check for weak-linked symbols. I don't know if the 11.1 SDK
actually added new APIs, but if so, building against it will result in
binaries that may not run on an 11.0 system. The 10.15 and 10.14 SDKs
definitely did add new APIs compared to 10.14 and 10.13 respectively.
The only viable solution is not to bake in the SDK path, or if you do,
recognise when the baked-in path isn't usable and drop it like python
does, and also respect configure.sdkroot when applicable.
In the case of build systems and compilers like GCC, using MacOSX.sdk at
runtime if nothing else is specified is fine of course.
More information about the macports-dev