Closed etcwilde closed 6 months ago
@swift-ci please test
Likely, once I get to moving those branches onto the newer distro releases.
macOS failure:
$ "/Users/ec2-user/jenkins/workspace/swift-corelibs-xctest-PR-macos/branch-release/5.10/swift-corelibs-xctest/Tests/Functional/Observation/Selected/Output/Selected" "Selected.ExecutedTestCase/test_executed"
# command stderr:
dyld[97367]: Symbol not found: _swift_getTypeByMangledNameInContext2
Referenced from: <487437FE-2357-335F-AD9D-FEA3D59ECD46> /Users/ec2-user/jenkins/workspace/swift-corelibs-xctest-PR-macos/branch-release/5.10/swift-corelibs-xctest/Tests/Functional/Observation/Selected/Output/Selected (built for macOS 14.2 which is newer than running OS)
Expected in: <087DADAD-D590-35EA-AC4D-7B0E966804EB> /usr/lib/swift/libswiftCore.dylib
This is the same thing we're seeing with 5.10 and the macOS bot on corelibs-Foundation. https://github.com/apple/swift-corelibs-foundation/pull/4953#issuecomment-2106646787
The most recent versions of
parse_version
throw an exception if the version is empty. The version passed in is only set on Darwin (call tomac_ver()
, so it's causing test failures on newer versions of Linux since the test suite can't even start.Now, the only reason for the version parse is because the tests are looking at whether or not concurrency is available on the OS. This is only a limitation if we're working with Darwin. Swift 5.10 on Windows and Linux always have a Swift 5.10 concurrency runtime, so we don't even need to check for a version.
rdar://128502662
https://ci.swift.org/view/Swift%205.10/job/oss-swift-5.10-package-debian-12/9/console