Will not build in generated Xcode projects
This may not be a bug in this package, but the following sequence of commands:
swift package init
# ... add dependencies as described in `README.md`
swift package update
swift package generate-xcodeproj
generates an Xcode project that fails to build with this error:
Undefined symbols for architecture x86_64:
"_swift_release_n", referenced from:
__sa_release_n in _AtomicsShims.o
"_swift_retain_n", referenced from:
__sa_retain_n in _AtomicsShims.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
This is using the code 12 beta 2 toolchain. A project in Xcode 12 beta2 builds correctly when this package is added via the Swift Package tab.
Package.swift:
// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "swift_atomic_test",
products: [
// Products define the executables and libraries a package produces, and make them visible to other packages.
.library(
name: "swift_atomic_test",
targets: ["swift_atomic_test"]),
],
dependencies: [
.package(
url: "https://github.com/apple/swift-atomics.git",
from: "0.0.1"
)
],
targets: [
// Targets are the basic building blocks of a package. A target can define a module or a test suite.
// Targets can depend on other targets in this package, and on products in packages this package depends on.
.target(
name: "swift_atomic_test",
dependencies: [
.product(name: "Atomics", package: "swift-atomics")
]
),
.testTarget(
name: "swift_atomic_testTests",
dependencies: ["swift_atomic_test"]
)
]
)
swift package generate-xcodeproj
Nowadays I don't think you should / need to rely on generating an Xcode project since Xcode is capable of just opening the SPM project directly: open Package.swift.
I can confirm that works just fine :)
The workaround for now is to manually add libswiftCore.dylib to the _AtomicsShims target's linked library list.
The root cause is that the module relies on a couple of symbols exported by the Swift Runtime that aren't part of its public interface.
swift package generate-xcodeproj
Nowadays I don't think you should / need to rely on generating an Xcode project since Xcode is capable of just opening the SPM project directly:
open Package.swift.I can confirm that works just fine :)
swift package generate-xcodeproj is still a standard command in the SPM and should be supported by Apple packages.
A little bit more detail as to why this is important to me, on the off-chance that someone from the Xcode team is reading this :)
Xcode does not, AFAIK, allow package dependencies to be editable. e.g. https://developer.apple.com/forums/thread/117570
I am working on a project with multiple layers of packages (for good reasons I won't go into here) I use a scripted workflow that puts the dependencies into edit mode with these commands:
swift package edit MRPCommon
swift package edit MRPConfiguration
swift package edit MRPProtocol
swift package edit MRPRuntime
swift package edit MRPInMemoryComponents
swift package edit MRPSwiftBinding
I can edit all of these packages in one Xcode project (in addition to the main multi-platform package), because it is generated after these commands are run. Although there are 7 git repos to deal with, there is only one Xcode project and edits do not have to be committed/pushed/pulled between repos before running.
This is why this support is important to me. Hopefully the need for the workaround is temporary. Ideally Xcode will support editable dependencies someday.
@ckornher Thanks for reporting this issue! I believe it is now fixed on main. Please reopen if you can still reproduce it with the current head revision.
Unfortunately the fix triggered a compiler issue (https://bugs.swift.org/browse/SR-13708), so I'll need to revert it.
I can edit all of these packages in one Xcode project (in addition to the main multi-platform package), because it is generated after these commands are run. Although there are 7 git repos to deal with, there is only one Xcode project and edits do not have to be committed/pushed/pulled between repos before running.
@ckornher One solution for this is to use a single Xcode workspace and drag all of the packages into that workspace. Xcode should then use the local copies to satisfy any dependencies rather than fetching them from the remotes.
In case Xcode project generation is still a thing these days, getting rid of the C module with something along the lines of https://github.com/apple/swift-atomics/pull/74 will likely eliminate these issues.
However, this will require some Swift compiler & stdlib work, so it will take additional time.
I believe https://github.com/apple/swift-atomics/pull/97 also resolves this (on the off chance the package works with a toolchain version that still supports generate-xcodeproj -- that command has been removed in some release before Swift 5.9.)