Merge #9130 'build: Fix for macOS 10.14/mojave'

fix #9050

Q: (from From #7891)
  > It turns out there's a difference between executing
  > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
  > and /usr/bin/clang. CMake was picking up the former and with that it left off
  > a key include path. Why?

A: /usr/bin/clang is a shim that uses libxcselect/libxcrun under the hood.
   $ otool -L /usr/bin/clang
   /usr/bin/clang:
    /usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)

From https://macops.ca/developer-binaries-on-os-x-xcode-select-and-xcrun/ :
  > this shim binary loads functions in libxcselect.dylib that can locate the
  > path to the real binary, depending on how the system has been configured. One
  > part of this process is to check whether this path contains
  > usr/lib/libxcrun.dylib, and the xcrun tool, in which case it will invoke
  > xcrun to run the binary.
  > ...
  > (If all of this isn’t yet enough indirection for you, /usr/bin/xcrun itself
  > is a shim, and so libxcselect.dylib contains code to detect whether the
  > executed xcrun is a shim. Look for the __xcrun_shim segment in the __DATA
  > section output by the command: pagestuff /usr/bin/xcrun -a.)

0 files changed, 0 insertions, 0 deletions