Force generation of ARM instruction set for iosArm32 and
watchosArm32 targets for C++ code. There is no need for such
adjustments for Kotlin code because we don't specify any target
features in IrToBitcode and compiler backend infers target features
from target architecture (which is armv7* and not thumbv7).
Caching is wrong when the compiler is working in Gradle daemon, because
the daemon can change the environment, while localKonanDir depends on
the environment.
As of Xcode 13.1 Swift 5.5 passes wrong libclang_rt to simulator targets
(similar to ours KT-47333). To workaround this problem, we explicitly
provide the correct one.
Previously initializing the DependencyProcessor will result in file IO.
In a fully-hermetic environment where all dependencies are local, this IO is redundant and may require the build system (e.g. Bazel) to do extra setup to ensure there is a local writable directory specified for these directories. This change will instead cause the dependency processor to bail early and skip downloading dependencies if all are local anyway.
Prior to this change kicking off a clean build with local dependencies would result in:
```
rm -rf ~/.konan/cache; fswatch -ax ~/.konan
~/.konan/cache Created IsDir
~/.konan/cache/.lock Created IsFile
```
After the change no FS operations are performed.
Clang-produced and GCC-produced binaries might be ABI-incompatible on
MinGW. Explanation on GitHub: msys2/MINGW-packages/issues/6855#issuecomment-680859662.
TL;DR: GCC-generated sections are 16-byte-padded, while Clang ones are
not. It causes problems during merge of COMDAT sections.
I observed the problem during compilation of runtime tests, but it is
possible that the problem could affect main compilation pipeline as well.
https://reviews.llvm.org/D86659 (which landed in LLVM 12) fixes
the problem. So we have another motivation for switching to LLD besides
https://youtrack.jetbrains.com/issue/KT-47605.
The only known downside is unsupported defsym which causes slight binary
size increase. I think it is doable.
The right way is to add something like KonanTarget.MSVC_X64, but doing
so requires changes throughout whole compiler. It would be especially
painful in HostManager, where we would need to deprecate
KonanTarget.MINGW_X64 as host. Instead we "hack" ClangArgs to compile
for x86_64-pc-windows-msvc instead of x86_64-pc-windows-gnu in JNI case.
CI may contain custom MSVC and Windows Kit installation path, so we
should support it. Things might break when machine has several MSVC
installed (at custom and default path), but it sounds more like
incorrect environment setup problem than ours.
Since LLVM for Windows is now native instead on MinGW, we have to
compile code in a different environment in case of JNI. This commits
just separates ClangArgs into two subclasses without actual behavior
changes.
We are going to switch to LLD linker for MinGW targets.
Right now LLD for MinGW doesn't support all features
of ld.bfd and thus this change might be breaking for some users.
To make transition smoother, we run lld -### to show a warning to user
so they can update their compilation options before LLD will be turned
on by default.
More details: https://youtrack.jetbrains.com/issue/KT-47605
SDKs from Xcode 12.5 contain C++ stdlib and it
breaks compilation of C++ parts of compiler.
Mitigate this problem by explicitly specifying
path to C++ stdlib.
Target triple (like `arm64-apple-ios-simulator`) is a common
way to represent any target platform.
One of many useful properties: it allows to explicitly
distinguish iOS arm64 simulator target and a real device.
Use `osVersionMinFlagClang` from konan.properties
instead of manual setup in ClangArgs.
This simplification will make it easier to add support
for future targets.
Sergey Bogolepov