Re: macOS 11 find-libs.mk POC

[Chris Hanson <cmhanson%eschatologist.net@localhost>]

On Aug 26, 2020, at 3:45 AM, Sijmen J. Mulder <ik%sjmulder.nl@localhost> wrote:
> 
> I agree this is the right approach in principle - if you want to see if
> a library can be linked, try to link it. However it's my understanding
> that this functionality needs to be available before we have selected a
> compiler.

You should generally use the compiler and linker provided by Xcode to target Apple platforms, in order to get the best compatibility.

> 2. Look for .tdb in the SDK instead of installed .dylibs in /usr/lib.

This is the route I would take if you absolutely need to know whether a library is present.

To find the macOS SDK provided by the selected Xcode, you can use xcrun and pass its identifier:

  $ xcrun --toolchain default --sdk macosx --show-sdk-path
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

This should always produce an absolute path, though users can rename Xcode and put it in directories with spaces, so be careful of quoting.

The `--toolchain default` portion is important to use with xcrun in case the person running this has additional toolchains installed (e.g. because they hack on the Swift compiler); of course that should be overridable since someone who is working on the compilers may want to build pkgsrc content using their in-progress work for testing purposes.

The part that I mentioned about "the selected Xcode" is also important as many developers on Apple platforms will have more than one installed; xcrun will use the developer's preferred tools as specified by xcode-select, unless DEVELOPER_DIR is overridden in the environment to point to a different Xcode.

An example of where this may be used is if a developer keeps a release version of Xcode as their "selected" Xcode but wants to try building with a beta Xcode; just overriding DEVELOPER_DIR in the environment to point into the beta instead is enough to cause invocations of xcodebuild, the compiler, the linker, etc. to run from the beta Xcode and use SDKs from it.

Finally, anything building binaries for Apple platforms that are intended to be shared needs to take into account two things: Deployment target and code signing.

"Deployment target" is what we call the minimum operating system version you want the code to run on. It's passed to the compiler via an argument like `-mmacosx-version-min=10.13` and to the linker via an argument like `-macos_version_min 10.13` and results in any APIs introduced after 10.13 being weak-linked. Also, if they're not used within an availability check, they'll generate warnings at compilation time. I *think* the tools also use MACOSX_DEPLOYMENT_TARGET if it's present in the environment for propagating, so you may not need to use a command line argument for it.

Code signing is how the OS verifies the provenance of code executing on the system and is critical for preventing malware distribution. Code can be ad hoc signed to run locally (say because it was built locally) but should be signed by a real certificate if it's being distributed to others, so if it winds up containing malware it can be prevented from running very quickly. Ensuring binaries built by pkgsrc for macOS can be signed with a real certificate is probably a sizable project though since I don't think it's the sort of thing that can be propagated via an environment variable.

  -- Chris
  -- not speaking in any official caacity