swiftDarwin and swiftOnoneSupport didn't depend on building the Swift core library.
This was a subtle bug, because the compiler just picked up the module from the SDK instead of the (still building) Swift module.
It only resulted in compiler errors if the SDK swiftinterface was too new to be parsable by the compiler.
Don't build the swiftCore module files in the bootstrapping phases. Instead use the module files in the SDK.
This reduces the build time overhead from 3min -> 30seconds.
Do not attempt to use a cross-compiled compiler for a foreign target. This is not guaranteed to work (e.g. building for ARM on x64). This at least surfaces the error properly.
The SwiftDriver searches `swift-frontend` based on `Bundle.main.executablePath` (which internally uses `CFGetProcessPath`). This search dir is resolved differently on macOS and Linux so swift-frontend can't be found on Linux, forcing the driver to fallback to using the host system toolchain instead of the just-built one.
* fix a typo which prevented linking the right bootstrapping libs
* build swiftDarwin for bootstrapping
* disable COW checks if built with bootstrapping-with-hostlibs
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
Also, add the libatomic dependency for Android armv7, just as on linux.
Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
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.
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.
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.
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.
