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.
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.)
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.
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.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
This adjusts the windows build for cross-compiling to use the correct
variable. Import libraries will be generated and tracked properly if
the CMAKE_SYSTEM_NAME is set to Windows. It does not matter what the
build system is.
Copy the runtime component into the swift runtime directory. Normally
the runtime directory is not the same as the library directory on
Windows. This copies the runtime component into the build tree into the
runtime directory to permit the tests to find the standard library.
Rather than have the ICU handling be pushed down into the library handling, this
will move it into the CFLAGS calulation which was being augmented previously.
It is a cleanup that makes it easier to reason about the flags handling.
Adjust the `c_compile_flags` variable to ensure that the flags are ordered
correctly. This is of import for the android build which may end up using
invalid header search path ordering otherwise. This ensures that the path
for the ICU includes comes after the C++ headers which is necessary in new
C++ releases which shadow math.h
Move the ICU flag handling to the same area as `_c_compile_variant_flags` which
computes the C compile flags. This allows us to ensure that we order the flags
correctly when they are merged into the `c_compile_flags`.
The CMake variables ${sdk} and ${arch} are only set if
_add_variant_link_flags is invoked from add_swift_target_library calling
_add_swift_library_single. If you get to _add_swift_library_single from
add_swift_host_library, those variables will not be set and subsequent
linking will not find ICU libraries. This was an issue when building
swift host libraries on Android.
This was used for the swift-reflection-test tool. Instead of using fat
binaries, use the target binary itself. This simplifies the build logic
as well as paves the road to sub-builds for each target rather than a
monolithic build as we have today.
Originally, the swift-reflection-test was a host tool that linked
against the target libraries since it was testing the target layout.
Now that the tool has been split into a host and target component
(5ea5bb06a3) and we have target and host
libraries that we can link against appropriately, we do not need to link
against the FAT binary. Since there was exactly one use of this
functionality, switching that from fat linking to regular linking allows
us to remove this functionality entirely. Switch to regular linking and
remove the option.
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
This is not currently being used. Unfortunately, setting linker options
is difficult until CMake 3.13 which introduced target_link_options.
Prior to that, you needed to do:
set_property(TARGET <TARGET> APPEND_STRING LINK_FLAGS <NEW FLAGS>)
If needed, we could write a helper to provide the target_link_options
interface on earlier CMake versions.
Whenever we're building C++ code as part of the Swift runtime or overlays,
disable the ABI-breaking checks. We are only using header content from
LLVM's ADT library.
Fixes rdar://problem/48618250.
* Enable linker dead stripping on Darwin
See r://48283130. This shaves 6MB+ off of swift and SourceKitService,
26.8MB off of swift-llvm-opt, 29.4MB off sil-passpipeline-dumper, etc.
* Disable dead stripping in Debug builds
It can hide linker errors caused by dependency cycles.
Unfortunately, `swift-reflection-test` links against the *TARGET*
library `swiftRemoteMirror`. The linked library is built as a target
library, which means that we use the custom library target construction
which suffixes the target with a variant spelling. Because the number
of variants is really high, we pass along the explicit EXPORTS macro
manually. However, we also build the library as a static library for
the *HOST*. This means that we need the sources to be aware of whether
they are built statically or dyanmically. This is accomplished by means
of the `_WINDLL` macro. The target library is shared and is built using
the custom wrapper for the library construction, which will create all
the variants and then use `_compute_variant_c_flags` which does not get
told what type of library is being built, so it assumes static and does
not append `_WINDLL`. This results in the shared library not exposing
any interfaces on Windows. When this happens, link will helpfully elide
the import library. The result of that is that the
swift-reflection-test binary will fail to link due to no import library
for the RemoteMirror. Explicitly add the -D_WINDLL if appropriate
manually after we have computed the C flags. *siiiiiiigh*
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
