Linux Support?

[mohok]

Linker error occurrs on Ubuntu 20.04, Swift 5.3 in resolving packages.

.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_load'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_load'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_compare_exchange'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_load'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_load'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_is_lock_free'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_is_lock_free'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_is_lock_free'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_compare_exchange'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_compare_exchange'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_compare_exchange'
.build/checkouts/swift-atomics/Sources/_AtomicsShims/include/_AtomicsShims.h:325: error: undefined reference to '__atomic_is_lock_free'
../.build/checkouts/swift-atomics/Sources/Atomics/autogenerated/IntegerConformances.swift:0: error: undefined reference to '__atomic_store'
../.build/checkouts/swift-atomics/Sources/Atomics/autogenerated/IntegerConformances.swift:0: error: undefined reference to '__atomic_exchange'
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)

[lorentey]

There are multiple problems, most of which have relatively straightforward resolutions:

1. The package definition is lacking a conditional link dependency on libatomics.so on Linux. (Triggered by support for double-wide atomics -- see point 4 below.)
2. One of the test cases has grown to >1600 tests, which triggers a compiler timeout while type checking the test registry. (Oops)
3. PR [shims] Make retain_n/release_n shims header-only #9 reintroduced a compiler issue (https://bugs.swift.org/browse/SR-13708).
4. Double-wide atomics need to be disabled on Linux/x86_64 unless cmpxchg16b support is manually enabled via -Xcc -mcx16. Declaring this to the package manager is tricky, but there are some potential workarounds. This does mean that for most Linux users, double-wide atomics won't be available.

[glessard]

Re: item 4
I thought that swiftlang/swift#29581 meant that Swift on Linux now requires a processor with cx16. If that is the case, shouldn't swift-pm be fixed to always compile with the -mcx16 flag?

[lorentey]

Oh, excellent catch! I agree completely -- swiftpm packages ought to build using the same target architecture as the stdlib itself. Given that the runtime unconditionally assumes a Core 2 system, it may be an even better option to skip swiftpm and change the compiler's defaults instead, so that everyone gets the right codegen independent of their build system.

I wonder if the stdlib really needs core2, or it could work with the narrower cx16 feature. (IIUC, core2 also enables SSE3/SSSE3 and SAHF. On the other hand, core2 conveniently matches the default arch on Darwin, and I expect it might be a universal baseline at this point, including for AMD processors.) (cc @drexin)

In the short term, we should probably update the instructions in the README to ask people to manually add -mcore2 rather than -mcx16 -- if only for consistency's sake.

If/when a version of SPM or swiftc ships that configures the target correctly, Package.swift will need to somehow figure out whether it is being compiled with the updated toolchain, and if so, then automatically define the ENABLE_DOUBLEWIDE_ATOMICS conditional flag. (I think the only way to do this right now is by basing the decision on an #if swift() or if compiler() conditional.)