Opened 3 years ago

Last modified 3 years ago

#62816 assigned defect

Buildbot: building XCode project on 10.14.4 fails with: Swift does not support the SDK 'MacOSX10.14.sdk'

Reported by: lhaeger (Lothar Haeger) Owned by: lhaeger (Lothar Haeger)
Priority: Normal Milestone:
Component: ports Version: 2.6.4
Keywords: Cc: lhaeger (Lothar Haeger)
Port: AutoRaise

Description

Please see https://github.com/macports/macports-ports/pull/10880 for the full log. It seems to me as if the buildbot is using the wrong combination of macOS/XCode/SDK here.

According to https://developer.apple.com/de/support/xcode/ XCode 11.3.1 on macOS 10.14.6 should be using the 10.15.2 SDK that came with that XCode version, not the 10.14 SDK that matches the macOS version but only came with XCode 10.x

I'm not sure if this is actually buildbot issue or something that would also kick in on end user machines.

Change History (10)

comment:1 Changed 3 years ago by kencu (Ken)

MacPorts specifically forces the SDK that matches the system version by default.

It can be changed with configure.sdkroot.

comment:2 in reply to:  1 ; Changed 3 years ago by lhaeger (Lothar Haeger)

Replying to kencu:

MacPorts specifically forces the SDK that matches the system version by default.

Seems as if that is too simple a default rule, maybe. Defaulting to the SDK that gets installed with the XCode Version used might be a better choice. Or would that break other ports...?

It can be changed with configure.sdkroot.

That’s good news, thanks a lot, I‘ll give that a try. I did not find the parameter format documented , though, is it just a version string like „10.15“?

comment:3 in reply to:  2 Changed 3 years ago by kencu (Ken)

Replying to lhaeger:

Replying to kencu:

MacPorts specifically forces the SDK that matches the system version by default.

Seems as if that is too simple a default rule, maybe. Defaulting to the SDK that gets installed with the XCode Version used might be a better choice. Or would that break other ports...?

feel free to raise that on the dev list if you choose

It can be changed with configure.sdkroot.

That’s good news, thanks a lot, I‘ll give that a try. I did not find the parameter format documented , though, is it just a version string like „10.15“?

here's an example

https://github.com/macports/macports-ports/blob/1f76293ecbd0cbf368ee373d878138a6712da718/devel/libsdl2/Portfile#L35

there is also another variable that could be manipulated, which might be simpler:

macosx_sdk_version           10.15

I'm not sure if that one also exists as configure.macosx_sdk_version, you'd have to check or wait for someone to chime in about it.

comment:4 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Pull requests and Buildbot have nothing to do with one another. For pull requests, mpbb runs on CI systems provided by GitHub. After a PR is merged or if a commit makes it to master by any other means, then mpbb runs via Buildbot on other servers.

MacPorts defaults to the SDK version that matches the OS version because it cannot in general be assumed that any given port can build with an SDK that does not match the OS version. Some may handle this ok, but the authors of many software packages are not aware of Apple SDKs and their software will not work correctly in this case.

configure.sdk_version is the version of the SDK (e.g. 10.15). Its default value is set from the macosx_sdk_version macports.conf value.

configure.sdkroot is the absolute path to that SDK (e.g. /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk).

If the SDK MacPorts wants to use does not exist, then it uses the unversioned SDK (MacOSX.sdk), which may, as I mentioned above, cause some ports to fail to build or work correctly if that unversioned SDK does not match the OS version.

comment:5 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Component: buildbot/mpbbports

comment:6 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from admin@… to lhaeger
Status: newassigned

comment:7 Changed 3 years ago by kencu (Ken)

so if you need the MacOSX.sdk or MacOSX10.15.sdk specifically on 10.14, instead of the MacOSX10.14.sdk, just set it, like I said, using configure.sdkroot.

And like the example I pointed you to, make sure it's actually there first :>

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:8 Changed 3 years ago by lhaeger (Lothar Haeger)

configure.sdk_version and/or configure.sdkroot are likely helpful to solve the issue, but I need to set it depending on the XCode version used, not (only) the macOS version. Anyone trying to build with XCode 10.x on macOS 10.14 will have to use the 10.14 SDK, while anyone using XCode 11.x on the same macOS 10.14 with need to use SDK 10.15.

So I'll read up on how to best determine the XCode version next...

comment:9 Changed 3 years ago by lhaeger (Lothar Haeger)

Does anyone know if the original SDK 11 that came with Xcode 12.2 would require configure.sdk_version 11 or configure.sdk_version 11.0 ?

comment:10 Changed 3 years ago by lhaeger (Lothar Haeger)

So adding code to force matching Xcode and SDK versions solved this issue for Xcode 11.3.1 on 10.14.6:

# fail if Swift 5 is not supported
if {[vercmp ${xcodeversion} 10.2] < 0} {
    known_fail yes
    pre-fetch {
        ui_error "${name} @${version} requires at least Xcode 10.2 with support for Swift 5."
        ui_error "See https://guide.macports.org/chunked/installing.xcode.html for download links."
        return -code error "incompatible Xcode version"
    }
}

# use the SDK version that came with the Xcode version in use, even if that does not match the macOS version
# see https://trac.macports.org/ticket/62816 for more details
if {[vercmp ${xcodeversion} 11.0] < 0} {
    configure.sdk_version 10.14
} elseif {[vercmp ${xcodeversion} 12.2] < 0} {
    configure.sdk_version 10.15
} elseif {[vercmp ${xcodeversion} 12.3] < 0} {
    configure.sdk_version 11
} elseif {[vercmp ${xcodeversion} 12.5] < 0} {
    configure.sdk_version 11.1
}

Note: See TracTickets for help on using tickets.