This converts the local variable to a cached variable which the user can
specify. By making this a cached variable, it is easier to control and
ensure that a default value is provided.
Rather than hardcoding the paths to /usr/include, allow the user to set
the path to their libc headers. This is particularly important for
environments which may not use the traditional layout (e.g. exherbo) or
for builds which wish to build against an out-of-tree, non-system
installed libc for a Unix target which does not match the host system
(i.e. foreign cross-compilation).
This just reorders the printed order of the messages to be grouped
better. This will be further augmented in the next set of changes which
improve the cross-compilation setup that we have currently to allow for
foreign environments better.
The clang in the android NDK (as well as the current stable Clang in
Swift) have a bug with Android x86_64 targets where the CPU's 16-byte
(double-word) CAS instruction feature is disabled resulting in the
double word CAS being lowered to a libcall
(`__sync_val_compare_and_swap_16`) rather than the CPU instruction
(`cmpxchg16b`). This results in the inability to link the content.
Work around this by enabling the feature manually in the build for now.
This is needed for cross-compiling the toolchain to Windows ARM64 on
Windows x64 using Visual Studio which does not permit the NATIVE
sub-build to work properly.
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
A previous change did the same change, but only for libraries. The
executables also need to be build to be linked as C to avoid clang++
automatic linking of C++.
Use the variable that holds the path to the ICU libraries to link
against ICU rather than hardcoding the names. This restores control to
the ICU linking to the way that traditional CMake `find_package` based
linking works.
Rather than using `-nolibstd++` which is not supported by the android toolchain,
use CMake's `LINKER_LANGAUGE` property on the targets. Since we explicitly link
against the C++ runtime anyways, this avoids the problem of having to remove the
C++ runtime from the link.
We need to pass `-fuse-ld=` `gold.exe` on Windows when targeting
Android. Given that we do not have a host toolchain for Linux on
Windows currently, do this unconditionally. This is required for
cross-compiling from Windows to android.
The host value is used as part of the path to the tools. The NDK only
has Darwin, Linux, and Windows prebuilts. Enumerate the hosts fully and
record an error message otherwise.
Android doesn't support the GNU backtrace call, but unwind.h is there to
help. The code is a little bit more complicated than a simple backtrace
call, but it is just a callback and the context struct.
Sadly, it seems that -funwind-tables is needed in every piece of code
that the backtrace needs to traverse, which means that at least the
runtime and the stubs need -funwind-tables. However, the flag has been
enabled for all targets (only on Android), just in case some other code
ends up being in the stack. This might only be necessary for ARM
targets, but currently we only build ARM targets in Android. The Swift
parts of the stack seems to have unwind information and can be unwind.
Another problem at the moment is the symbols from the executable are
normally missing. To get symbol names two things need to happen: the
symbol has to be public (so it is an exported symbol, and not just a
local symbol that dladdr seems to not provide the name), and the linker
has to be invoked with -export-dynamic. Without those two pieces, the
addresses are returned (and match the binary just fine), but no names
are printed.
Although it's a static archive, its use is only relevant to dynamically linked builds of the
standard library. (If you're statically linking a Swift runtime into your process, you don't
need to worry about compatibility with older runtimes.)
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
Ensure that we build all the target libraries with the correct build
configuration. This is needed on Windows where the different MSVC
runtime libraries are ABI incompatible.
These properties are extraneous. They are never queried, and the
`set(...CACHE)` which precedes them will ensure that the value is
cached. This should be functionally equivalent.
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
Preconditions have been moved to the top of the file. All the variables set have been grouped by kind and a few converted to cache variables for better control when building. This should cut down on merge-conflicts as well."
clang/cmark are only needed for the tools, not for the runtime/SDK
overlay. Do not attempt to configure clang and CMark in the case we do
not build the tools. This is needed to enable the standalone standard
library only builds.
Now that that's stabilized, we don't have to keep them in Swift 4 mode
any longer. (Arguably we don't need the CMake variable at all, but it
may be useful again in the future.)
rdar://problem/49040980
