Some headers switch their inline implementations based on
SWIFT_STDLIB_SINGLE_THREAD_RUNTIME definition.
This fixes linking failure while building runtime unittests
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.
When building on Windows i686 with a toolchain build for Windows x64, we
would try to build libdispatch for i686 as x86_64. This obviously would
be incorrect. Explicitly pass the target triple for the sub-builds. We
can do this unconditionally since we always use `clang-cl` builds. This
allows us to build the SDK only components for Windows i686 from a 64bit
build.
This adds a cache for a configuration of the standard library for
Windows x86 configurations. This should help restore the x86 builds of
the SDK for Windows.
Introduce an additional build product to build-script to build
back-deployable concurrency libraries. These libraries would need to
be embedded in apps deployed prior to macOS 12/iOS 15 to support
concurrency.
The built-script option `--back-deploy-concurrency` can be provided to
build these back-deployment libraries. They are built in addition to
the normal concurrency libraries, as a separate product that installs
into `lib/swift-5.5/<platform>` within the toolchain. The macro
`SWIFT_CONCURRENCY_BACK_DEPLOYMENT` is set when building the
concurrency library, so that we can adapt the implementation to older
OS's.
Using `support` llvm component ends up adding `-Xlinker /path/to/lib/libLLVMDemangle.a`
to `LINK_FLAGS` but `libLLVMDemangle.a` is not added as an input to the linking ninja statement.
As a workaround, in order to setup precise inputs for the ninja link statement, include `demangle` component
whenever `support` is mentioned.
Add the default target triple to match the target for the Windows
toolchain. This avoids the need for an additional parameter, and
it makes sense for the target to be the host by default. Explicit
parameters can change the target when desired.
This ensures that we pick up libraries from the toolchain before picking up
libraries from the SDK we are using. Normally it would not matter the order that
we add these -L files since the contents of the SDK and toolchain are
disjoint. Once we begin performing stage2 swift builds though, we no longer have
this property since we pass in the stage1's installed libraries as the SDK
directory and we have not split the two sets of libraries yet. The end result is
that if we have the -L in the previous order, we will pick up just built
compatibility libraries before we pick up the actual compatibility libraries
from the actual toolchain we are using to compile. This results in compilation
breakage.
The mangler fuzzer and reflection fuzzer build was broken, both by a problem in
the CMake scripts and also because of changes that have happened in other parts
of the code.
After talking with compnerd, because we're passing this directly to the
swift driver, we shouldn't have to do anything weird with the flags and
it should "just work". I'm frustrated enough with Windows that I'm just
going to go with that and go to bed. If I broke something, I'm sorry. I
tried as far as my sanity would allow.
This patch fixes the part of the build system where we aren't passing
the sanitizer flags to swift, so the linker isn't linking against the
sanitizer libraries.
* add the (still empty) libswift package
* add build support for libswift in CMake
* add libswift to swift-frontend and sil-opt
The build can be controlled with the LIBSWIFT_BUILD_MODE cmake variable: by default it’s “DISABLE”, which means that libswift is not built. If it’s “HOSTTOOLS”, libswift is built with a pre-installed toolchain on the host system.
We have two directories for Swift libraries,
* `SWIFT_SDK_<platform>_LIB_SUBDIR`, a.k.a., the SDK subdir,
a.k.a., `swift-<platform>-<arch>/lib/swift/<platform>`, and
* `SWIFTLIB_SINGLE_SUBDIR`,
a.k.a., `swift-<platform>-<arch>/lib/swift/<platform>/<arch>`.
Through the Swift build, libraries are emitted to both
`.../lib/swift/<platform>` and `.../lib/swift/<platform>/<arch>`.
However, when building toolchains, only `.../lib/swift/<platform>/` is
populated with libraries.
None of this normally isn't a problem; the Swift libraries do not have
inherent interdependencies. This however changes with Concurrency:
Concurrency has an implicit dependency on libdispatch.
When Swift is built, we have two copies of `libswift_Concurrency.so`:
one in `.../lib/swift/<platform>` and one in
`.../lib/swift/<platform>/<arch>`. Prior to this commit, we
unconditionally copy `libdispatch.so` and `libBlocksRuntime.so` to only
_one_ place -- that is, `.../lib/swift/<platform>/<arch>`.
swiftc emits binaries on ELF systems with an rpath of
`.../lib/swift/<platform>`. These binaries implicitly import
Concurrency, so they link against `libswift_Concurrency.so` (whether
they use Concurrency features or not). The library's `$ORIGIN` is
searched to find `libdispatch.so`.
Now, nothing breaks on Linux because there the loader, when given an
rpath, searches both `.../lib/swift/<platform>` and
`.../lib/swift/<platform>/<arch>` even though the rpath only specifies
one directory..
However, on other platforms, only the given rpath is searched.
`libdispatch.so` does not reside next to `libswift_Concurrency.so`
because it has been copied to `.../lib/swift/<platform>/<arch>`; not in
the rpath.
There are a few ways to solve this: change the way rpaths are
configured, only emit libraries into one place, copy `libdispatch.so`
only to the path matching the rpath, or copy `libdispatch.so` wherever
`libswift_Concurrency.so` is copied,
Because the toolchain file layout is different to the file layout when
only Swift is built, hacking the rpath is brittle. Presumably, the
reason why we have a `libswift_Concurrency.so` residing in two places is
to support builds where multiple architectures are supported in the one
build directory, so we cannot just copy `libdispatch.so` _only_ to
`.../lib/swift/<platform>`.
Ultimately, We need to ensure that every instance where
`libswift_Concurrency.so` can be used has `libdispatch.so` residing next
to it, which we do here.
Note that this implicit dependency resolution would not happen unless we
added a `-ldispatch` flag to make this all work, but other platforms are
instaed using `$ORIGIN` to get the search to work properly, so we also
do this for OpenBSD in this commit.
This is just cruft that remained from the time when swift's host/target used the
same cmake code. Host tools do not statically link against just built artifacts.
The official builds include the profiling library, so we should enable
it on the CI to ensure that the path is tested. This should only add
~1m to the total build time.
There are three things going on here (note all on Darwin):
1. If one compiles a swift static library and links the static library into a
cxx executable, the cxx executable will need the -L flags to find the
appropriate libraries in the SDK/toolchain.
2. I fixed an rpath issue where due to old code I didn't understand/propagated
forward, we were setting the rpath to be the -L directory in the appropriate
SDK. After reasoning about this a little bit I realized that this was code
that was actually intended to be used for target libraries (for which the
given rpath would be correct). On the host side though on Darwin, we want to
use the rpath for the standard stabilized stdlib on the system.
3. I added Build System Unittests to ensure that this keeps on working. I also
added test cases that I should have added before. I just had never thought
about how to test this and I realized this method would work and would
prevent regressions while I am waiting for a new swiftc with driver fixes to
land.
Before a8ae9525aa, we could not do this since we
would fail to link since we didn't pass to clang the path to the toolchain dir
when the compatibility libraries live.
Clang and Swift both support this so we can do this until the actual fix lands
in a host toolchain to unblock ErikE.
The specific problem is the swift driver should just push tbd files through to
the linker, but it treats it as an input file. I am going to be putting a fix
into 5.5. This patch in the mean time filters out the tbd files in cmake. This
is a temporary fix.
I also had to add direct dependencies from swift-refactor and
libSwiftSyntaxParser on LLVMSupport to ensure that the right linker flags get to
them.
I already did this for executables. The reason why we must do this is that right
now there are bugs in cmake's swift support that makes it so that one can not
use swiftc to link targets with mixed c/c++/swift content even if the swift
content is indirectly added via linking. To work around this we must also ensure
that all libraries with mixed c/c++/swift objects link using clang. As an
additional side-effect of this, we must pass to the clang linker -L flags that
swiftc would normally provide for the linker. The two cases where I needed to do
this were:
1. -L path for the compatibility libraries. This path points into the toolchain
where these live. This is important since otherwise we will fail to link given
the minimum deployment target that swift (both host/stdlib) target today (10.9).
2. -L path to the SDK. This path points to the SDKs lib/swift/${HOST_PLATFORM}
for swiftCore and friends.
That being said, we still want people to be able to link pure swift libraries
using swiftc, so we introduce an option called PURE_SWIFT to add_host_library
that preserves this and is used to also set
IGNORE_LLVM_UPDATE_COMPILE_FLAGS (which arguably should have been called
PURE_SWIFT).
As a postprocessing step for unittest executables, `utils/swift-rpathize.py` unconditionally rewrites the install name of any library linked from /usr/lib/swift to be `@rpath`-relative, in an effort to load the just-built libraries instead of the OS-supplied ones.
This works great for dylibs like libswiftCore.dylib that are built as part of the toolchain, but `/usr/lib/swift` also includes a huge number of overlay dylibs that are no longer part of this repository. These dylibs must ~always be loaded from the OS location.
In order to prevent load-time issues, we need to add /usr/lib/swift to the rpath, so any libraries that we haven’t built will be picked up from there.
We could also do this by extending swift-rpathize.py with an allow (or deny) list, but keeping the list up to date would generate a bunch of maintenance work we could do without.
