When cross-compiling for android ARM, it is possible that the system
linker does not support the target. However, in order to cross-compile
the target runtime, we need to adjust the linker to the target linker.
If one is not specified, fall back to the current behaviour of using the
system linker.
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
This breaks the build on exherbo, which uses target tripled linker
names. Furthermore, the default name on unix-ish systems for the linker
is `ld`. This can be a symlink to a specific implementation, usually
named as ld.<name> (e.g. `ld.bfd` or `ld.gold`). Use the cmake variable
for the linker rather than hardcoding the name.
- Create separate swift_begin.o/swift_end.o for lib/swift and
lib/swift_static. The static swift_begin.o does not call
swift_addNewDSOImage() at startup.
- Update ToolChains.cpp to use the correct swift_begin.o/swift_end.o
files for the `-static-stdlib` and `-static-executable` options.
- Rename swift::addNewDSOImage() to swift_addNewDSOImage() and
export using SWIFT_RUNTIME_EXPORT.
- Move ELF specific parts of ImageInspection.h into
ImageInspectionELF.h.
- For ELF targets, keep track of shared objects as they are
dynamically loaded so that section data can be added to
the protocol conformance and type metadata caches after
initialisation (rdar://problem/19045112).
The runtime and stubs are built for ALL targets, not specific ones. This allows
us to configure when cross-compiling to Windows again. Collapse the dual
addition of the swiftRuntime into a single build. This unifies the runtime
build for the apple and non-Apple SDKs. The difference here was the ObjC
interop sources. In order to deal with that unification add a CPP macro to
indicate whether the interop sources should be included or not.
- 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
The code we use to interface with the platform dynamic linker is turning into a rat's nest of conditionals that's hard to maintain and extend. Since ELF, Mach-O, and PE platforms have pretty fundamentally different dynamic linker interfaces and capabilities, it makes sense to factor that code into a separate file per-platform, instead of trying to conditionalize the logic in-line. This patch factors out a much simpler portable interface for lazily kicking off the protocol conformance and type metadata lookup caches, and factors the guts out into separate MachO, ELF, and Win32 backends. This should also be a much cleaner interface to interface static binary behavior into, assisting #5349.
The `add_swift_library` CMake function takes an optional `TARGET_SDKS`
parameter. When used, only CMake targets for the specified SDKs are added.
Refactor `stdlib/public/runtime` to use this parameter. This also eliminates
logic that determines additional flags or source files to include based on
`SWIFT_HOST_VARIANT`, which makes it easier for hosts to add targets for
different platforms.
Rather than having Sema provide a default implementation of
Error._code when needed, introduce a runtime function to extract the
default code, so that we can provide a default implementation via a
protocol extension in the standard library.
If the Swift error wrapped in a _SwiftNativeNSError box conforms to
Hashable, the box now uses the Swift's conformance to Hashable.
Part of rdar://problem/27574348.
If there's no better mapping for a Swift value into an Objective-C object for bridging purposes, we can fall back to boxing the value in a class. This class doesn't have any public interface beyond being `NSObject`-conforming in Objective-C, but is recognized by the Swift runtime so that it can be dynamically cast back to the boxed type.
When the standard library is built dynamically on COFF targets, the public
interfaces must be decorated in order to generate a proper DLL which can be
confused by the dependent libraries. When the exported interface is used, it
must be indirectly addressed. This can be done manually in code or the MS
extension of `__declspec(dllimport)` may be used to indicate to the compiler
that this symbol be addressed indirectly. This permits building more pieces of
the standard library dynamically on Windows.
Always include all the sources as we cannot include object libraries to be
subsumed. This allows us to conditionally build the swift runtime for foreign
hosts simultaneously (e.g. cross compile for Linux and Windows simultaneously).
Build the section_magic libraries for all the ELFish SDKs that have been
configured. This allows us to build for SDKs which dont match the object format
at the same time (e.g. Linux and Windows).
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
This patch is for libswiftCore.lib, linking with the library set of Visual Studio 2015. Clang with the option -fms-extension is used to build this port.
This is the approved subpatch of a large patch.
Declarations with protected visibility are assumed to be defined
within the current linkage unit, so we have to use default visibility
if we don't know that we're building that. Teach the shim
visibility header to only use protected visibility when the
__SWIFT_CURRENT_DYLIB macro is defined, and define it when building
the standard library. Eventually we should change
SWIFT_RUNTIME_STDLIB_INTERFACE and SWIFT_RUNTIME_EXPORT to be
parameterized by the defining dylib so that this works for all the
overlay stubs, too; for now, special-casing swiftCore is necessary
to fix the LInux build.
This adds an Android target for the stdlib. It is also the first
example of cross-compiling outside of Darwin.
Mailing list discussions:
1. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151207/000171.html
2. https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000492.html
The Android variant of Swift may be built using the following `build-script`
invocation:
```
$ utils/build-script \
-R \ # Build in ReleaseAssert mode.
--android \ # Build for Android.
--android-ndk ~/android-ndk-r10e \ # Path to an Android NDK.
--android-ndk-version 21 \
--android-icu-uc ~/libicu-android/armeabi-v7a/libicuuc.so \
--android-icu-uc-include ~/libicu-android/armeabi-v7a/icu/source/common \
--android-icu-i18n ~/libicu-android/armeabi-v7a/libicui18n.so \
--android-icu-i18n-include ~/libicu-android/armeabi-v7a/icu/source/i18n/
```
Android builds have the following dependencies, as can be seen in
the build script invocation:
1. An Android NDK of version 21 or greater, available to download
here: http://developer.android.com/ndk/downloads/index.html.
2. A libicu compatible with android-armv7.
- added read / write lock support
- added non-fatal error support to allow use of mutex in fatal error reporting pathway
- isolated pthread implementation to it own header/cpp file pair
- expanded unit tests to cover new code as well as better test existing mutex
- removed a layer of complexity that added no real value
Generate global symbols which are function pointers to the actual implementations of runtime entry points.
This is done only for entry points using the new calling convention or for those entry points which explicitly require it.
