On 2017-9-29 18:48 , Leonardo Brondani Schenkel wrote:
On 2017-09-29 10:23, Joshua Root wrote:
On 2017-9-29 18:14 , Leonardo Brondani Schenkel wrote:
This seems to be an issue in XCode 9 to me, since I believe that when
setting the deployment target to 10.12 or earlier it should not be
exposing symbols that are not available at runtime.
It is working correctly as far as it goes; autoconf just doesn't solve
the entire problem. Symbols that are not available on all the OS
versions being targeted must be checked for at runtime before use.
That way a single binary can use newer APIs when they are available
but still run on older OS releases.
Fair enough. I think I don't fully understand the role of "deployment
target": to me it was the *maximum* version I want to be able to link
against, but apparently it is the opposite.
The SDK you build against determines the latest APIs that can be used
(MAC_OS_X_VERSION_MAX_ALLOWED) while MACOSX_DEPLOYMENT_TARGET (which
affects MAC_OS_X_VERSION_MIN_REQUIRED) determines the oldest OS on which
the binary can run.
That means, symbols available on MAC_OS_X_VERSION_MIN_REQUIRED are
linked normally, while symbols that are available on
MAC_OS_X_VERSION_MAX_ALLOWED but not MAC_OS_X_VERSION_MIN_REQUIRED are
weak linked, and trying to use symbols that are not available on
MAC_OS_X_VERSION_MAX_ALLOWED results in a link error.
However, the motivation for my the original post was more to talk about
if it makes sense to have something done on MacPorts level to mitigate
this issue or just deal with it on a port-by-port basis. Just to be
clear: I'm not advocating one or the other — I'm just curious about what
the lists thinks.
Well, our installation instructions say to install the Command Line
Tools, which avoids this problem. I guess we could try setting
MAC_OS_X_VERSION_MAX_ALLOWED explicitly, but unlike
MACOSX_DEPLOYMENT_TARGET, it isn't picked up from the environment by the
compiler driver, so a lot of ports would require special handling to get
it into the CPPFLAGS.
- Josh
