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.
This is much faster than the full "bootstrapping" mode.
On linux, the default stays "bootstrapping", because "bootstrapping-with-hostlibs" is not supported.
In CI:
* Build two presets with "bootstrapping", so that this mode is tested on macOS at least on some bots.
* Do the macOS smoke test also with "bootstrapping-with-hostlibs". It only adds ~30 sec compared to "hosttools" which was used previously.
This is for the 'freestanding' build to stop assuming the platform has argc/argv.
- Introduce a new sub-library, libswiftCommandLineSupport.a
- Move stubs/CommandLine.cpp into this library
- Conditionally embed it into libswiftCore
- Conditionally embed it into libswiftPrivateLibcExtras if not in libswiftCore to support testing
- Add SWIFT_STDLIB_HAS_COMMANDLINE CMake (and build-script) flag
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.
And set this option in various presets for buildbots.
Don't enable the checks by default because when linking against the OS library (which does not support COW checking) it will result in unresolved symbol errors.
So far it was handled by an availability checks against 9999 (which was a hack), but this does not work anymore.
Note, all this is only relevant for assert builds of the stdlib.
rdar://83673798
Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
Otherwise, we can't successfully dry-run a toolchain on darwin.
I added an option enable-extract-symbol-dry-run-test that can be set to restore
the previous behavior and updating the BuildSystem unit tests that depend on
that behavior to pass that flag.
Add three new flags, '--skip-clean-libdispatch', '--skip-clean-foundation', and
'--skip-clean-xctest', that leave the previous builds of those products in place.
This is to avoid the following issue when generating toolchains for
macOS
```
ld: building for tvOS, but linking in object file built for tvOS
Simulator, file '/tmp/strip.mgCPcB' for architecture i386
fatal error:
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip:
internal link edit command failed
```
This reverts commit 8470faf309, #37929
Addresses rdar://80098850
- If any of the `-g<kind>` flag is given -- except `-gnone`, debug
info will be printed into every generated SIL files.
- The `-gsil` is deprecated in favor of `-sil-based-debuginfo`. The
SILDebugInfoGenerator Pass now generates intermediate SIL file with
name "<output file>.sil_dbg_<n>.sil". Other functionalities of that
Pass remain the same.
Pass the Swift and CMake flags needed to cross-compile Foundation and so on, with
the first example of Android. Add a new flag, --cross-compile-deps-path, which is
used to search for cross-compiled libraries, like libcurl, that the corelibs
depend on. Also add a new flag, --common-swift-flags, to pass additional Swift
flags to the corelibs.
* 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.
This would be needed to reduce overall build times in scenarios when
generating symbols for all binaries is too expensive and/or not needed.
At the same time, introduce tests around the logic that handles symbols.
Addresses rdar://76865276
This would be needed to reduce overall build times in scenarios when
generating symbols for all binaries is too expensive and/or not needed.
Addresses rdar://76865276
...before adding the logic to filter paths
In particular:
* print the list of files that `cpio` copies, so we can test explicitly
which files end up in the symroot (and also see those when asking for
a toolchain in PR testing)
* use `find` instead of `grep` to filter files we want symbols generated
for -- this is to avoid the script failing when there are no symbol to
process, especially in lit tests
* remove an unnecessary check for `swift-api-digester` -- this is now a
symlink to `swift-frontend` and we only process regular files.
Supports rdar://76865276
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
This library is contained in `lib/swift/<OS>/`, which `recursive-lipo` assumes contains the stdlib, and other Swift code built fat from the get-go. `libSwiftScan` is a part of the compiler build, and is therefore built for the host in a given build, which means toolchain installation requries that we use `lipo` to produce a fat shared library for it.
Resolves rdar://74490218
This is meant to support scenarios in which we need to build as little as
LLVM as possible for performance reasons (e.g. when enabling LTO).
While LLVM CMake build system offers options in this sense,
in our investigation they turned out not to be suitable,
since either they are not granular enough (`LLVM_INCLUDE/BUILD` flags)
or they require active opt out for any new tool added
(`*_BUILD_*_TOOL` flags)
When using this mechanism, there is the possibility to specify different
targets to use for cross-compile hosts.
Supports rdar://32019390
