LLVM FreeBSD triples include the version number, which gets encoded into
the swiftmodule. The filename should not include the version number
though. This patch drops the version number from the filename, but not
from the target triple.
This fixes several tests which uses the computed target triple as the
flag to pass to `-target`. Since it was missing the version number, the
compiler assumed it defaulted to zero and would report
"compiling for freebsd 0, but module 'Dispatch' has a minimum deployment
target of freebsd 14.3"
Fixes: rdar://156163594
Currently we are using the same versions we use to build compiler and
standard library. This is an unnecessary coupling especially when
testing the generation of backdeployed executables for macOS -- here
we have interest in being able to run the tests on previous OSes, not
the compiler itself.
To support this, add new `--darwin-test-deployment-version-<platform>`
flags to build-script, which by default take the same value as the
matching `--darwin-deployment-version-<platform>` ones.
Addresses rdar://156724078
The tests broke on the community Android CI since #82325, and I just
noticed the install issue when cross-compiling Testing with a
freshly-built compiler, which I'd never done before. Also, fix the NDK
path shown in the CMake output.
The 64-bit ARM architecture spelling on FreeBSD is aarch64, not arm64.
This results in a build failure about a missing
`freebsd/arm64/swiftrt.o` while building the runtimes.
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
This is a little less than ideal, since as I understand it, it only
makes sense to add -z,origin when $ORIGIN expansion is required, but
doing this surgically per target is rather cumbersome. I don't believe
there are any significant drawbacks to doing it unconditionally like
this, however.
This patch adds initial support for Emscripten SDK alongside the existing
support for WASI SDK. This is a first step towards building a part of
Swift compiler for Emscripten target (which will be used to build LLDB
with Swift to WebAssembly target).
* Reapply '[BuildSystem] Stop building for i386-watch-simulator (#77692)'
* [BuildSystem] Stop building for i386-watch-simulator
In Xcode16 it is not supported.
This initially broke client projects who were still building the legacy
architecture but now that's resolved.
* Revert "[Build] Fix swift_build_support tests."
This reverts commit fc2d1b3b23.
* Revert "[BuildSystem] Stop building for i386-watch-simulator (#77692)"
This reverts commit 1ab968d2b6.
This change can't be made without other issues fixed downstream first.
However, to do this, we end up changing how amd64 is supported too.
Previously, I had tried to keep some meaningful separation between
platform spelling and LLVM spelling, but this is becoming more difficult
to meaningfully maintain.
Target specifications are trivially converted LLVM triples, and the
module files are looked up by LLVM triples. We can make sure that the
targets align, but then the Glibc to SwiftGlibc import breaks. That could
also be addressed, but then we get to a point where the targets set up
by build-script and referenced by cmake begin to misalign. There are
references in build-script-impl for a potential renaming site, but it's
not quite enough.
It's far simpler to give up and rename to LLVM spellings right at the
beginning. This does mean that this commit is less constrained to just
adding the necessary parts to enable arm64, but it should mean less
headaches overall from differing architecture spellings.
This means we will get build IDs in the tools and standard library,
which is useful for debugging (it lets us associate debug symbols with
the binaries later on, as well as allowing us to reliably identify
exactly which binary we are looking at).
rdar://116525111
Declare a new `LINUX_STATIC` SDK and configure it.
Add options to set the build architectures for the `LINUX` and
`LINUX_STATIC` SDKs, similar to what we have for Darwin, because
we'll be cross-compiling.
Also add an option to point the build system at the sources for
the musl C library, which we're using for `LINUX_STATIC`.
rdar://123503470
The WASI community is transitioning to a new naming for the "preview"
version in the target triple: wasm32-wasi -> wasm32-wasip1.
At this moment, we keep the old triple wasm32-wasi because it's already
widely used, but we should start using the new triple threaded target.
LLVM checks only if the OS field *starts* with "wasi", so "wasip1" is
still considered a valid `isOSWASI()` target.
See: https://github.com/WebAssembly/wasi-libc/pull/478
This patch adds a new CMake option, `SWIFT_ENABLE_WASI_THREADS`, to
enable building the Standard Library using WASI threads primitives
(https://github.com/WebAssembly/wasi-threads). With this option, the
Standard Library will be built for the new "wasm32-unknown-wasi-threads"
target. We add the new triple because the WASI threads proposal requires
extra syscalls and object files compiled to "wasm32-unknown-wasi" and
"wasm32-unknown-wasi-threads" are not compatible and cannot be linked
together.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
This macro was previously substituted when generating `glibc.modulemap` file during the compiler build. Now Swift detects the location of Glibc dynamically and injects `glibc.modulemap` into it using LLVM VFS. The last usage of `GLIBC_INCLUDE_PATH` was removed in `78c0540b`.
This also removes `SWIFT_SDK_${sdk}_ARCH_${arch}_LIBC_INCLUDE_DIRECTORY` which doesn't have any usages left.
With a properly prepared sysroot and toolchain file, these changes permit
cross-compilation of Swift as well as LLVM, CMark, and Dispatch (picking,
as usual, apple/swift-corelibs-libdispatch#556) from a Linux host
generating OpenBSD binaries.
The toolchain file must be specified as an environment variable to
`build-script` and discussion on how to properly set up the sysroot and
toolchain file will be handled later.
Added a check that someone hasn't passed us an argument with too many
colons. Also renamed `find_threading_package` to `get_threading_package`
to better reflect what it does.
These are better done via the SwiftConfigureSDK mechanism rather than
how I was doing them previously. Additionally, I've changed the way
that the swift-threading-package option works. In addition to
specifying just a single package name, you can specify it as a CMake
list (i.e. separate by semicolons) of colon-separated `sdk:package`
pairs, e.g. `osx:darwin;linux:pthreads`. You can also override it
for all SDKs and then specify for a given SDK; specifications for a
particular SDK take precedence over the global override. For instance
`pthreads;osx:darwin` says to use `pthreads` except on the OS X SDK
where we should use `darwin`.
Allow Linux distributions to provide their own C++ flags to compile the
C++ overlay correctly. The default is kept the same for Ubuntu and
CentOS, but other distributions can provide other flags to use their own
distro GCC stdlibc++ or even libc++ if they choose.
This should not change the current compilation, but opens the door for
other maintainers to provide a different value that work on their
systems.
Paths to WASI SDK sysroot should not assume `/share/wasi-sysroot` directory hierarchy. It's much more flexible to have this part hidden under the more general `SWIFT_WASI_SYSROOT_PATH` variable.
* [Concurrency] Fix Android C libdispatch build
We need to pass CMAKE_ANDROID_NDK and CMAKE_ANDROID_ARCH_ABI to the
build.
* Set proper ANDROID_ARCH_ABI
* Add -DCMAKE_ANDROID_API to C libdispatch build
* Fix compiler config for Android
