There was a ton of copy-paste in the various embedded swift library
builds. Centralize most of that logic into a new
add_embedded_swift_target_library function that will make it easier to
make additional libraries build as embedded swift.
Sink settings for various Swift library build options that have fixed
values for Embedded Swift down into the AddSwiftStdlib logic, rather
than duplicating them in every embedded library build.
The ONLY_SWIFTMODULE option was used for some of the Embedded Swift
library builds to produce just a .swiftmodule without any
corresponding object files or static archives. This presupposes a
build model where we never emit object code for these libraries;
rather, it all gets inlined into the clients.
To make it possible to add more flexibility to the build model here,
drop this option. Instead, pass along the flags to emit an empty
object file and set the code generation model to "implementation".
This is effectively the same code generation model (since the object
file is empty), but made more explicit and done in a manner that fits
in better with the build system.
Use this as an excuse to centralize setting a number of other Embedded
Swift-specific flags, rather than copy-pasting them for every library
built as Embedded Swift.
Clang enables -mrelax by default, which isn't compatible with
-gsplit-dwarf. This fixes the -r build on Linux, which currently fails while
compiling the riscv-64 stdlib.
* to check for the presence of the archiver, use `EXISTS`/`IS_DIRECTORY`
instead of `IS_EXECUTABLE`
* use `$<JOIN:...>` instead of `$<LIST:JOIN,...>` to compose the
archiving commands
* to be on the safe side, perform the check on the archiver only if
we are building the embedded stdlib
when building non Darwin architectures with Xcode 26.4 beta 1 and later
-- the archiver that ships in Xcode is guaranteed to work only on MachO
object files, and will generate empty archives for other executable
formats.
This is a temporary solution while we add the support to build the
Embedded Swift stdlib in the new Runtimes build system.
Addresses rdar://171007411
`-define-availability` arguments for stdlib modules can be very long,
which may exceed Windows command-line length limits and cause build
failures. Use response files to avoid this.
We have a private oslog library to test optimizations specific for oslog.
Add -assert-config DisableReplacement to this library similar to the real oslog library.
This prevents surprizing optimizer regressions.
This doesn't have a working symbolicator yet, but it does build and
it can obtain a basic backtrace.
It also doesn't include a working `swift-backtrace` program yet.
rdar://101623384
This is second version of #85621 which was reverted in #85794 because
the result of `_compute_lto_flag` was used as a boolean in some
contexts.
The differences from the original is that `_compute_lto_flag` is split
into a second function `_is_lto_enabled` which provides an actual
boolean for when LTO is enabled, and the half dozen usages of
`_compute_lto_flag` have been audited for using `_compute_lto_flag`
without considering the return value a boolean, or using the new
`_is_lto_enabled` as a proper boolean. A small clean up of commented out
code is performed (probably just a forgetten clean up from #66077).
The changes have been verified by compiling with
`SWIFT_STDLIB_ENABLE_LTO=thin` and
`SWIFT_STDLIB_BUILD_TYPE=RelWithDebInfo`, and checking the resulting
flags for building the stdlib include both `-flto=thin` and
`-gline-tables-only`, while the Swift tools include `-fno-lto` instead.
The following is the original commit message, which explains why this
change is interesting:
---
When compiling Swift as an LLVM external project (not the non-unified
workflow from the build-script), if one tries to enable LTO for LLVM
projects it will end up affecting Swift and the Swift standard library,
even if the options `SWIFT_TOOLS_ENABLE_LTO` and
`SWIFT_STDLIB_ENABLE_LTO` are disabled or using their default values,
because [HandleLLVMOptions] modifies the `CMAKE_C/CXX_FLAGS` globally.
By setting `-fno-lto` explicitly when those options are disabled or
using their default values, the options from `CMAKE_C/CXX_FLAGS` are
overriden, and the `SWIFT_*_ENABLE_LTO` controls the usage or not of LTO
optimizations and the presence of bitcode in the object files.
[HandleLLVMOptions]:
https://github.com/swiftlang/llvm-project/blob/b58b2a34d5094928c4ee1b94a7d5412b14540c01/llvm/cmake/modules/HandleLLVMOptions.cmake#L1278-L1310
Stripping out the logic behind enabling concurrency tracing
independently of the rest of the standard library tracing. It's not
clear that there is a use-case where we want one without the other.
We don't want library evolution turned on for the Static SDK.
We can't do this in the `StdlibOptions.cmake` file because that's
testing the *host*, not the *target* (the code in there is wrong).
rdar://160455139
Where someone has told a target library to build for a _newer_ target
than the current deployment target, we need to respect that newer
target when setting StdlibDeploymentTarget for that target library.
This trips us up when testing against older systems.
rdar://155841439
Add catalyst support for SwiftStdlibCurrentOS.
Also, set a minimum deployment target when building Concurrency;
this stops the build failing when we're trying to build on older
systems where Concurrency didn't really exist yet.
rdar://150966361
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 was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
To do this we also need to fix AddSwiftStdlib because if you set the
`INSTALL_WITH_SHARED` flag, the CMake scripts don't make a target
with the `-static` suffix, but AddSwiftStdlib also assumes that it
should dad `-static` to any module dependencies when building a
static library.
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.
Add a new bits/ header to the Android overlay, include runtime libraries that are
auto-extracted and listed many times to the list of libraries to be de-duplicated,
enable a C++ interop test that's working again, and update the doc with new
libraries that need to be available to run a simple executable.
These modules import Darwin which is not in ossa. -enable-ossa-modules
results in a one-time recompilation of dependencies when they are not in ossa.
This is not compatible with Explicit Build Modules when the original invocation
did not have -enable-ossa-modules.
This fixes linker warnings that look like this:
```
ld: warning: object file (libswiftCompatibility56.a) was built for newer 'macOS' version (XYZ) than being linked (ABC)
```
These were caused by the compatibility binary being incorrectly built with a newer `-target` than desired: the CMake logic was overriding the requested minimum macOS deployment version (10.9) with a much newer macOS SDK version.
rdar://137565964
add_swift_target_library was missing pieces for passing sources and
flags to the static SDK build. As a result, the static SDK was missing
pieces (specifically Mutex).
Also adding the Musl import to the Linux Mutex implementation.
We need to make sure that we build swift-backtrace with a deployment target
newer than 10.14.4 in order that we get linked against
`/usr/lib/swift/libswiftCore.dylib` rather than using an `@rpath`-based
path.
If we fail to do that, dyld becomes confused and we end up crashing with
weird errors about missing method implementations on `Swift.__StringStorage`.
To make this work, add support for `DEPLOYMENT_VERSION_*` in the
`add_swift_target_executable()` CMake function. And since I spotted a bug
in it, fix the existing support in `add_swift_target_library()` while I'm
there.
rdar://132710670
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
Adrian Prantl
Mishal Shah
Doug Gregor
Max Desiatov
Allan Shortlidge
Eric Miotto
Rintaro Ishizaki
Meghana Gupta
Meghana Gupta
Alastair Houghton
Daniel Rodríguez Troitiño
Evan Wilde
Mads Odgaard
Erik Eckstein
Marc Prud'hommeaux
Kuba Mracek
QuietMisdreavus
Slava Pestov
Hamish Knight
Finagolfin
3405691582
Saleem Abdulrasool
Egor Zhdan
Vera Mitchell
Evan Wilde
Alex Lorenz
Alejandro Alonso