Currently, when having both ASan and UBSan enabled, the compiler is
passed "-sanitize=address -sanitize=undefined" which results in error:
invalid value 'address -sanitize=undefined' in '-sanitize='. Pass the
two flags separately to fix the issue.
Use the include search path for the header search rather than
constructing the path using relative paths. This is important for
getting the interop to work properly as well.
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
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.
When building with unified builds, `CMAKE_SOURCE_DIR` is not the Swift
repository. Use the locally defined `SWIFT_SOURCE_DIR` variable to
reference the root of the Swift repository. Because libswift uses
`project` in the CMakeLists, we cannot use `PROJECT_SOURCE_DIR` here.
Fixes a linux build error.
It doesn’t make sense to let add HAS_LIBSWIFT to add_swift_host_library(). This was added to work around a linker bug (d22b348adb). Instead do the workaround in libSwiftScan/CMakeLists.txt.
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.
