Hi,
I understand that all objects and static libraries linked into one executable need to be compiled with the same deployment target. Is it OK to static link objects that were compiled with the same deployment target but different SDK versions?
Is it OK to static link objects that were compiled with the same deployment target but different SDK versions?
What’s the source language for this object files?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
In my use case, it's all plain C (not Objective-C).
In my use case, it's all plain C
The lower in the language stack you go, the less likely you are to encounter problems here. And C is about as low-level as it gets (-: Historically there have been cases where the SDK version changed C code [1] but I can’t think of anything that’s relevant on current systems.
Having said that, this sort of thing definitely makes me queasy. There might be problems right now that I’m simply not aware of, or you might encounter new problems down the line. Doing stuff like this takes you off the well-trodden path, and there are always pitfalls out there. Sticking to the path is always safer.
Finally, there’s a big picture issue in play here: Our platforms have a bunch of backwards compatibility code that’s enabled if the main executable is linked to an older SDK. But that only checks the main executable. If other code, regardless of whether it’s statically or dynamically linked, was linked to a different SDK, it may or may not get the compatibility behaviour depending on the context in which it’s loaded. That can produce some ‘interesting’ bugs O-:
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] This was related to the Single UNIX Specification efforts back in the macOS 10.5 days. And that’s .5, not .15!
