pinentry-mac does not build with Xcode 15

[szhorvat (Szabolcs Horvát)]

pinentry-mac does not build on my macOS 13.6 system, probably because I have Xcode 15. Log file is attached. gnupg2 depends on this port, and lots of other ports depend on gnupg2.

[Dave-Allured (Dave Allured)]

Starting logging for pinentry-mac @0.9.4_1
sysinfo macOS 13.6.2 (darwin/22.6.0) arch arm
sysinfo MacPorts 2.8.1
sysinfo Xcode 15.0.1, CLT 15.0.0.0.1.1694021235
sysinfo SDK 13
sysinfo MACOSX_DEPLOYMENT_TARGET: 13.0

:info:build error: failed to deserialize Info.plist task context: Deserialization failed: SDK lookup failed for canonical name: macosx13.3 (in target 'pinentry-mac' from project 'pinentry-mac')

[FlyingSamson]

According to the ​"Minimum requirements and supported SDKs" table on this side starting with XCode15 only SDK 14 is supported.

Since the upstream project of pinentry-map has been archived a long time ago, I was wondering if this should still be preferred over pinentry by the gnupg2 port, which seems to be the only port depending on pinentry-map. If not, I would suggest changing the logic in gnupg2's portfile (sorry could not yet figure out how to link code in GitHub in the WikiFormatting yet)

platform darwin {
    if {![variant_isset pinentry] && ![variant_isset pinentry_mac]} {
        # Automatically switch between pinentry and pinentry-mac, with pinentry-mac being
        # preferred.
        # 10.7 and below are not supported by pinentry-mac, though, and will default to
        # pinentry. Just like pure darwin without OS X will.
        if {${os.subplatform} ne "macosx" ||
            ${xcodeversion} eq "none" ||
            [vercmp ${xcodeversion} {5.0}] < 0 ||
            ${os.major} < 12 || (![catch {registry_active pinentry}] &&
                                 [catch {registry_active pinentry-mac}])} {
            default_variants-append +pinentry
        } else {
            default_variants-append +pinentry_mac
        }
    }

    if {${os.major} < 9} {
        patchfiles-append   patch-common_sysutils.c-fix-unsetenv-usage-on-10.4.diff
    }
}

to prefer pinenty for macOS < 10.7 and "pure darwin" (current state) AND if Xcode version >= 15.

Would that be sensible?

[FlyingSamson]

In the meantime if anybody should stumble upon this issue, two workarounds:

• explicitly request gnupg2+pinentry to force using pinentry
• or, if gnupg2 Is also just pulled in as a dependency of another port, you can also install pinentry first causing above cited code to chose the +pinentry variant of gnupg2 automatically.

[ryandesign (Ryan Carsten Schmidt)]

Replying to FlyingSamson:

According to the ​"Minimum requirements and supported SDKs" table on this side starting with XCode15 only SDK 14 is supported.

Yes but it has been the case for over a decade that the latest Xcode compatible with a version of macOS only contains the next major macOS version's SDK, and Apple doesn't think that's a problem; it's possible* to build software on macOS 13 for macOS 13 using the macOS 14 SDK, for example. So the task would be to discover why this build is deliberately looking for the nonexistent macOS 13 SDK and to convince it instead to use the SDK that MacPorts told it to use (which is the one you have). There are other open tickets of similar problems in other ports, so if you figure out how to fix this, you may be able to fix those as well.

*There are cases where some software fails to build this way because it detects capabilities of the later SDK and tries to use them, ignoring the requested earlier deployment target. But that's not what we're talking about in this ticket.

[FlyingSamson]

OK, thank you, for that explanation! I wasn't aware of that.

I searched around a bit and found that port Sequal-Ace seemed to have faced a similar issue, in the case that the macOS version was behind the SDK version (the portfile gives the example of macOS 10.15 running Xcode 12). Similarly, Szabolcs, Dave, and myself see the problem in this ticket when building on macOS 13 using Xcode 15, which in therory provides SDK 14 but the build still uses SDK 13 matching the OS version.

I tried applying the workaround used in Sequel-Ace:

pre-configure {
    # This port really needs to use the Xcode SDK, not CLT SDK for some
    # currently unknown reason.
    #
    # With the base logic in portconfigure.tcl there is currently no way to
    # force the selection of an Xcode SDK in the case that Xcode has something
    # newer than the OS: e.g. macOS 10.15 running Xcode 12 will never choose
    # Xcode's MacOSX11.0.sdk and will always choose the CLT MacOSX10.15.sdk.
    #
    # There is no consensus on what can or should be done about this; see
    # https://lists.macports.org/pipermail/macports-dev/2020-November/042621.html
    #
    # Thus we do this hacky thing: at runtime choose the best Xcode SDK
    # possible.
    if {[catch {exec xcrun --sdk macosx${configure.sdk_version} --show-sdk-path 2> /dev/null} sdk]} {
        ui_debug "Failed to find Xcode SDK for macosx${configure.sdk_version}; trying macosx"
        catch {exec xcrun --sdk macosx --show-sdk-path 2> /dev/null} sdk
    }
    if {${sdk} ne ""} {
        ui_debug "Found Xcode SDK ${sdk}"
        configure.sdkroot  ${sdk}
    }
}

which indeed also fixed building pinentry-mac (i.e., this ticket).

While I kind of understand that this fixes the issue, I do not understand how this is not required by all the other ports using the xcode portgroup for building. This makes me think that there must be more to the problem with pinentry-mac.

[FlyingSamson]

I do not understand how this is not required by all the other ports using the xcode portgroup for building

Further search through trac and github revealed, that this was indeed a misperception. This issue is indeed quite reproducible across several ports:

• ssh-askpass-mac
• graphviz-gui
• TeXShop

all of which showing the same error when build on macOS 13.x using Xcode 15.x. Because the SDKROOT is set to the location of SDK 13.

[FlyingSamson]

Replying to ryandesign:

So the task would be to discover why this build is deliberately looking for the nonexistent macOS 13 SDK and to convince it instead to use the SDK that MacPorts told it to use (which is the one you have).

From what I gathered so far, it is looking for SDK 13.3 because:

• the SDKROOT passed in the failing command is set to /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk.
• This stems from the xcode portgroup where SDKROOT is set to ${configure.sdkroot}.
• configure.sdkroot by default is set in portconfigure.tcl to [portconfigure::configure_get_sdkroot ${configure.sdk_version}].
• configure.sdk_version by default is set to $macosx_sdk_version which by default is set to $macos_version_major in macports.tcl and results in 13 in the failing instances.
• Then configure_get_sdkroot receiving this sdk_version of 13 for some reason that I do not yet understand must return the path to the existing CLT SDK 13.

[FlyingSamson]

OK I get it now.

configure_get_sdkroot checks:

• if /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13 exists, which for Xcode 14 it does not.
• Then it attempts to find a SDK with "close" version in the same directory, which means having the same major version of 13. Again this does not exist for Xcode 14.
• Then it searches for a cached sdkroot with version 13 or tries to find one using xcrun --sdk macosx13 --show-sdk-path and xcrun --sdk macosx13.6.6 --show-sdk-path also without success.
• Then it searches for /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk which exists and will be returned.
• Only if this would also fail would it try to find a newer SDK using the command xcrun --sdk macosx --show-sdk-path, which is also the one used by the Sequel-Ace portfile to set the sdkroot directly.

In configure_get_sdkroot this fallback is commented with

    # Support falling back to "macosx" if it is present.
    #       This leads to problems when it is newer than the base OS because many OSS assume that
    #       the SDK version matches the deployment target, so they unconditionally try to use
    #       symbols that are only available on newer OS versions..

From this I gather that it is not an option to make this more of a default.

This leaves me with the question: Do we generally assume that building with the CLT SDK with the same version as the OS (i.e., 13 in this case) works? From your statement

So the task would be to discover why this build is deliberately looking for the nonexistent macOS 13 SDK and to convince it instead to use the SDK that MacPorts told it to use (which is the one you have)

I would understand that we would indeed not assume the CLT SDK 13 to work and should somehow tell him to use the non-CLT SDK 14.

[ryandesign (Ryan Carsten Schmidt)]

Yes, we assume that the SDK version whose major version matches the running macOS version is the best way to build a port, so that's what MacPorts does, and doesn't really provide good support for using any other SDK.