[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-pkg
Subject:    Re: macOS 11 find-libs.mk POC
From:       Chris Hanson <cmhanson () eschatologist ! net>
Date:       2020-08-26 20:54:48
Message-ID: 814CEEE3-E940-485C-89DE-AD1ED2DDBF7B () eschatologist ! net
[Download RAW message or body]

On Aug 26, 2020, at 3:45 AM, Sijmen J. Mulder <ik@sjmulder.nl> 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


[prev in list] [next in list] [prev in thread] [next in thread]