This will allow us to have multiple parallel installations of swiftCore
with the same DLL name allowing us to side-step the ABI instability
without resorting to SOVERSIONing.
This is in preparation for using Win32 SxS assembly manifests to permit
co-installation of the runtimes on Windows without an ABI consideration
and allow users to select between the revision.
Use the static module constructor for swiftCore on Windows as the
runtime functions are internal to the module. This fixes the last linker
warning that we see with the standard library build when building
dynamically. More importantly, this allows building swiftCore as a DLL
with the new build system on Windows as we now treat any linker warnings
as errors.
This introduces the new variant of the `swiftrt.obj` - `swiftrtT.obj`
for Windows. This follows the C standard library naming convention as
set forth by GCC.
`crtbegin.o` => used to find constructors
`crtbeginS.o` => used to find constructors in DSOs/PIEs
`crtbeginT.o` => used to find constructors in static executables
The newly minted `swiftrtT.obj` is meant for static linking. The one
exception to this is building the swift runtime itself which locally
defines the symbols and thus should always use the static variant.
These libraries are now implicitly explicitly linked. The source files
include `#pragma comment(lib, ...)` to include the autolink directives
to properly handle the dependency propagation to ensure static linking
is sufficiently closed.
Use a full 3-component version specifier as that is required for some
support on Windows. The version number components will be used to
generate the Win32 SxS manifest for embedding within the DLL.
The main goal for now is to have this building, with little
concern about matching the build flags used currently.
Keep it disabled by default on Apple platforms.
Addresses rdar://143151393
`SWIFT_STDLIB_HAS_MALLOC_TYPE` is defined in terms of
`SWIFT_STDLIB_HAS_DARWIN_LIBMALLOC` in `include/swift/Runtime/Config.h`.
Apple platforms generally have the Darwin libmalloc, so it should be a
safe bet to define it this way. Unfortunately, a lot of things include
the Config.h file, transitively or otherwise, so figuring out exactly
which libraries should have this defined vs ones that should not is
rather tricky, so for now, I've defined it globally.
We were previously silently emitting incorrect code for the standard
libraries and the warnings were being swallowed by the build system.
This was brought to light by the new build system. The code generation
issues have been addressed. In order to prevent a backslide, we would
ideally use `/WX:4217 /WX:4286`. Unfortunately, `clang-cl` does not
support this, so compromise and use `/WX` which treats all linker
warnings as errors.
Add an option to enable emitting a stacktrace on calls to `fatalError`.
This is unrelated to the runtime backtracer for diagnosing normal Swift
crashes.
rdar://142440689
In some configurations, libraries are installed under
`<install-prefix>/{libdir}/swift/<platform>/<arch>` and module content
is installed under `<install-prefix>/{libdir}/swift/<platform>`.
This also accounts for the fact that Swift currently looks under
`<install-prefix>/{libdir}/swift_static/**` for the static stdlib
builds.
With swiftlang/swift#78717 we now can extract the platform and
architecture subdirectories required for deploying the files.
Restructure the code when adding this functionality to invoke the
command once and then extract the various fields that we need.
Remove a `-disable-implicit-backtracing-module-import` that was added
in `Runtimes/Core/CMakeLists.txt`, and also remove the reference to
`swiftCxxStdlib` from `RuntimeModule` as that causes the build to fail
when attempting to build the static version of `swift-backtrace` on
Linux.
rdar://124913332
Add the missing `ObjCShims.h` header to the installed header set.
Without this the module is incomplete. This was detected on Windows when
trying to build the SwiftShims module.
Install the Swift registrar into the correct location for the SDK. This
file is to be placed into /usr/lib/swift/<platform>/<arch> with the name
`swiftrt.[o|obj]`.
...building the stdlib for Apple platforms.
For now we want to match the flags the existing configuration (which is
already accounted by the default values provided by CMake) -- in
particular the generation of full symbols and usage of whole module
optimization.
Addresses rdar://142620659
These set of Swift flags are applied to all runtime libraries that are
built. Hoist them to the top-level to spell them once and to keep all
the libraries in sync.
