Linking directories from `_add_variant_link_flags` of were overwritten
in `_add_swift_executable_single` by not using the
`LIBRARY_SEARCH_DIRECTORIES` parameter.
`LIBRARY_SEARCH_DIRECTORIES` is actually being used as
`RESULT_VAR_NAME` to affect the value on the parent scope. In this
context `LIBRARY_SEARCH_DIRECTORIES_VAR_NAME` sounds like a better name.
PIC on windows does not make sense. All code is position independent.
Currently clang and LLVM do the wrong thing and generate ELF style PIC
code on Windows when `-fPIC` is used. Add `-fno-pic` to disable that
when cross-compiling to Windows.
When the code was refactored, the old variable name `libkind` was left
in a couple of spots. Update them to `kind`. Remove unnecessary
quoting which would have exposed this bug.
Introduce a swift_target_link_search_directories which allows you to
append a search path to the linker. This interface also allows a tweak
to make the library search directory addition more portable across
compilers (e.g. cl vs clang).
for sib/sibgen files for libraries without building them by default.
This will let engineers just cd into the build directory and type:
ninja swift-stdlib-sib
ninja swift-stdlib-sibgen
To generate sib and sibgen files respectively.
There are still some dependency issues in between the sib targets, so to get
this to work well, I would suggest doing a full build and then using these
targets.
These headers should be treated as system headers as we do not control them.
Use target_include_directories so that we can use the `SYSTEM` option to
indicate that they are system headers. It also simplifies the invocation by not
directly modifying the underlying property.
These are the commands Pete added in 5834df3, doing slightly more work
by compiling Swift sources twice in order to start building downstream
libraries sooner.
Really, we should diagnose when -embed-bitcode is passed here, instead
of generating nonsense commands and then falling over. I filed
https://bugs.swift.org/browse/SR-3352 for that.
rdar://problem/29537164
- Add ImageInspectionStatic.cpp to lookup protocol conformance
and metadata sections in static binaries
- For Linux, build libswiftImageInspectionShared.a and
libswiftImageInspectionStatic.a for linking with libswiftCore.a.
This allows static binaries to be built without linking to
libdl. libswiftImageInspectionShared (ImageInspectionELF.cpp) is
automatically compiled into libswiftCore.so
- Adds -static-executable option to swiftc to use along with
-emit-executable that uses linker arguments in
static-executable-args.lnk. This also requires a libicu
to be compiled using the --libicu which has configure options
that dont require libdl for accessing ICU datafiles
- Static binaries only work on Linux at this time
Currently SwiftOnoneSupport.o waits on Swift.o to finish compiling before we start
compiling SwiftOnoneSupport.o. We don't need the .o for compilation but instead just
need Swift.swiftmodule which we were generating anyway.
This change causes .o and { .swiftmodule, .swiftdoc } to be built independently of each
other. Downstream compiles only wait on the module while downstream links wait on the .o.
Given that .apinotes are sometimes used by swiftc invocations, this also separates out
apinotes in to its own step which these other commands can both depend on.
The result of this is a 30% improvement in building the stdlib with -R and 20% with -d.
Specifically, -R drops from 3m to 2m and -d drops from 12m to just under 10m.
Fixes the Android build, and makes some adjustments for Android NDK r13.
* Fix FindICU.cmake to properly set the `SWIFT_${sdk}_ICU_UC` and
`SWIFT_${sdk}_ICU_I18N` values. These were not properly set because
"uc" and "i18n" were lowercase.
* Adapt `add_swift_library` to parse `ICU_UC` and `ICU_I18N` for
private link libraries and use the proper `SWIFT_${sdk}_ICU_*` values.
* NDK r13 removes a subdirectory from the llvm-libc++ includes path.
Adapt to this change, and add a FIXME to address this issue before it
may break again.
* Update the documentation to point to a new libicu download for NDK 13.
This reverts commit 23987b26f3.
I originally thought that I was going to need this for LTO work. Now it is just
dead code.
Even if we were to enable this though it wouldn't fix the underlying issue since
swiftc would still emit bitcode that may be incompatible with the host compiler.
So reverting this makes the most sense.
The Swift runtime can be built for Android on Linux host machines using
the instructions in `docs/Android.md`. This commit allows a static build
of the runtime to be compiled on macOS host machines as well.
This work is inspired by @compnerd's work in enabling Windows builds
from macOS hosts. It assumes host tools are already built for macOS. It
also does not support building SDK overlays yet. I intend to support these in a
future commit.
For now, the Android runtime may be built by using the following bash
script, which simply calls CMake:
```sh
set -e
set -x
HOME_DIR="/Users/bgesiak"
APPLE_DIR="${HOME_DIR}/GitHub/apple"
BUILD_DIR="${APPLE_DIR}/build/Ninja-Release"
CMARK_SRC_DIR="${APPLE_DIR}/cmark"
CMARK_BUILD_DIR="${BUILD_DIR}/cmark-macosx-x86_64"
LLVM_SRC_DIR="${APPLE_DIR}/llvm"
LLVM_BUILD_DIR="${BUILD_DIR}/llvm-macosx-x86_64"
SWIFT_BUILD_DIR="${BUILD_DIR}/swift-macosx-x86_64"
ANDROID_NDK_DIR="${HOME_DIR}/android-ndk-r12b"
LIBICU_SRC_DIR="${APPLE_DIR}/libiconv-libicu-android"
LIBICU_BUILD_DIR="${LIBICU_SRC_DIR}/armeabi-v7a"
SWIFT_ANDROID_BUILD_DIR="${APPLE_DIR}/build/SwiftAndroid"
mkdir -p "${SWIFT_ANDROID_BUILD_DIR}"
cmake \
-G "Ninja" \
\
-DCMAKE_C_COMPILER:PATH="${LLVM_BUILD_DIR}/bin/clang" \
-DCMAKE_CXX_COMPILER:PATH="${LLVM_BUILD_DIR}/bin/clang++" \
\
-DSWIFT_PATH_TO_CMARK_SOURCE:PATH="${CMARK_SRC_DIR}" \
-DSWIFT_PATH_TO_CMARK_BUILD:PATH="${CMARK_BUILD_DIR}" \
-DSWIFT_CMARK_LIBRARY_DIR:PATH="${CMARK_BUILD_DIR}/src" \
-DSWIFT_PATH_TO_LLVM_SOURCE:PATH="${LLVM_SRC_DIR}" \
-DSWIFT_PATH_TO_LLVM_BUILD:PATH="${LLVM_BUILD_DIR}" \
-DSWIFT_PATH_TO_CLANG_SOURCE:PATH="${LLVM_SRC_DIR}/tools/clang" \
-DSWIFT_PATH_TO_CLANG_BUILD:PATH="${LLVM_BUILD_DIR}" \
-DSWIFT_NATIVE_LLVM_TOOLS_PATH:STRING="${LLVM_BUILD_DIR}/bin" \
-DSWIFT_NATIVE_SWIFT_TOOLS_PATH:STRING="${SWIFT_BUILD_DIR}/bin" \
\
-DSWIFT_ANALYZE_CODE_COVERAGE:STRING=FALSE \
-DSWIFT_SERIALIZE_STDLIB_UNITTEST:BOOL=FALSE \
-DSWIFT_STDLIB_SIL_DEBUGGING:BOOL=FALSE \
-DSWIFT_CHECK_INCREMENTAL_COMPILATION:BOOL=FALSE \
-DSWIFT_STDLIB_ENABLE_RESILIENCE:BOOL=FALSE \
-DSWIFT_STDLIB_SIL_SERIALIZE_ALL:BOOL=TRUE \
-DSWIFT_BUILD_PERF_TESTSUITE:BOOL=FALSE \
-DSWIFT_BUILD_EXAMPLES:BOOL=FALSE \
-DSWIFT_INCLUDE_TESTS:BOOL=FALSE \
-DSWIFT_EMBED_BITCODE_SECTION:BOOL=FALSE \
-DSWIFT_TOOLS_ENABLE_LTO:STRING= \
-DSWIFT_AST_VERIFIER:BOOL=TRUE \
-DSWIFT_SIL_VERIFY_ALL:BOOL=FALSE \
-DSWIFT_RUNTIME_ENABLE_LEAK_CHECKER:BOOL=FALSE \
\
-DCMAKE_BUILD_TYPE:STRING=Release \
-DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE \
-DSWIFT_STDLIB_BUILD_TYPE:STRING=Release \
-DSWIFT_STDLIB_ASSERTIONS:BOOL=TRUE \
-DSWIFT_BUILD_RUNTIME_WITH_HOST_COMPILER:BOOL=TRUE \
-DSWIFT_HOST_VARIANT=macosx \
-DSWIFT_HOST_VARIANT_SDK=OSX \
-DSWIFT_HOST_VARIANT_ARCH=x86_64 \
-DSWIFT_BUILD_TOOLS:BOOL=FALSE \
-DSWIFT_INCLUDE_TOOLS:BOOL=FALSE \
-DSWIFT_BUILD_REMOTE_MIRROR:BOOL=FALSE \
-DSWIFT_BUILD_DYNAMIC_STDLIB:BOOL=FALSE \
-DSWIFT_BUILD_STATIC_STDLIB:BOOL=TRUE \
-DSWIFT_BUILD_DYNAMIC_SDK_OVERLAY:BOOL=FALSE \
-DSWIFT_BUILD_STATIC_SDK_OVERLAY:BOOL=FALSE \
-DSWIFT_EXEC:STRING="${SWIFT_BUILD_DIR}/bin/swiftc" \
\
-DSWIFT_ENABLE_GOLD_LINKER:BOOL=TRUE \
-DSWIFT_SDKS:STRING=ANDROID \
-DSWIFT_ANDROID_NDK_PATH:STRING="${ANDROID_NDK_DIR}" \
-DSWIFT_ANDROID_NDK_GCC_VERSION:STRING=4.9 \
-DSWIFT_ANDROID_SDK_PATH:STRING="${ANDROID_NDK_DIR}/platforms/android-21/arch-arm" \
-DSWIFT_ANDROID_ICU_UC:STRING="${LIBICU_BUILD_DIR}" \
-DSWIFT_ANDROID_ICU_UC_INCLUDE:STRING="${LIBICU_BUILD_DIR}/icu/source/common" \
-DSWIFT_ANDROID_ICU_I18N:STRING="${LIBICU_BUILD_DIR}" \
-DSWIFT_ANDROID_ICU_I18N_INCLUDE:STRING="${LIBICU_BUILD_DIR}/icu/source/i18n" \
\
"${APPLE_DIR}/swift"
cmake --build "${APPLE_DIR}/swift" -- -j8 swift-stdlib-android-armv7
```
This approach side steps the whole dependency issue between the lipo target and the codesign target by just combining them (if needed). This is accomplished by moving the codesign code into `_add_swift_lipo_target` and having it conditional on passing `CODESIGN` as an option.
This patch also updates `_add_swift_lipo_target` to use named arguments instead of positional ones, and provides a little bit of cleanup. There is more opportunity for larger refactoring and cleanup here by not generating a lipo target at all on non-darwin platforms.
When building on a macOS host, and when `SWIFT_INCLUDE_TESTS` is specified,
the `swiftSwiftReflectionTest` target is added to all platforms.
However, this target has a dependency upon Foundation, which is not
available on non-Apple platforms.
Use `add_swift_library`'s `TARGET_SDKS` parameter and other gating
logic to ensure the target is only added for platforms that actually
have Darwin available.
This reverts commit 10506e00c0.
There are dylibs in lib/swift/macosx/x86_64/ and lib/swift/macosx/, and
with this patch the dylibs in the latter path don't get updated when the
code changes and are stale.
I'm not sure exactly how to correct this patch so let's just try again
when it updates both sets of dylibs.
rdar://28660201
The CMake variable `APPLE` is set to true when building on a macOS
host, which means that logic to include linker flags for application
extensions, etc., will be enabled on a macOS host. That is, they will
be enabled even when cross-compiling the standard library to a
non-Apple platform, such as Android.
Instead of using `APPLE` to check the host OS, check whether the target
is an Apple platform.
When compiling the Swift standard library for Android on Linux, the
target prefixes and suffixes for static and shared libraries happen to
be the same for both platforms. When using a macOS host to compile,
however, the suffixes are different, causing build errors.
Explicitly set the prefixes and suffixes to prevent errors when
building on macOS.
Checking CMAKE_SYSTEM_NAME to append Darwin-specific flags happens to
work when cross-compiling from one Darwinian system to another -- like
using a macOS host to build the standard library for iOS. It doesn't
work, however, when cross-compiling from macOS to Android, for example.
Instead of checking the host system name, check whether the SDK target
is Darwinian.
Swift's CMake build system creates "fat" binaries for Swift libraries,
so long as the host machine used to compile the libraries is a macOS
machine. However, when a non-Darwin target, such as Android, is being
compiled on a macOS host, this doesn't work. Instead, only add lipo
targets if the *target* is Darwin.
