To make this work:
* expose SwiftCMakeConfig.h from the Core build
system, to support scenarios in which the downstream Distributed build
is leveraging the config files generated by CMake itself.
* adjust how SwiftShims is defined in `FindSwiftCore.cmake`, so that the
shims are found from C++ and that we don't get redefinition errors
when multiple module maps are in the search paths.
Fixes#83449
Addresses rdar://149241603, rdar://157165530
This removes the workaround for the exporting of the registrar and
enables proper dependency tracking across projects (primarily geared
towards the Overlay).
`swiftrtT.obj` should be used for statically linking the standard
library (or within the standard library itself). For the other modules,
we need to differentiate between `swiftrt.obj` and `swiftrtT.obj`. This
fixes that oversight. This was not caught by the CI builds as we do not
currently build both the static and dynamic variants of the new
runtimes.
The driver just changed where it looks for swiftrt.o when performing a
static-stdlib build from always looking under `/usr/lib/swift` to
`/usr/lib/swift_static`.
This change of behavior comes from:
7156812d251d0f4dd6e7c605940f7e5497eaa795
Starting to work on a full installation story for the Swift runtimes.
This involves generating the SwiftCoreConfig cmake files to allow
importing the just-built runtimes into the overlays and supplemental
libraries, setting up the flags appropriately for the given SwiftCore
build configuration.
This also separates out the development and runtime components to allow
installing just the runtimes without the headers.
Component List:
- SwiftCore_runtime
The runtime libraries that are required for running code.
- SwiftCore_development
The interface with the runtime libraries that are required for
building code against the runtimes.
- SwiftCore_cmake
Files for interfacing CMake projects with the built runtimes.
This includes the target list and flags needed to use the targets
built by the specific configuration used to build the runtime
libraries.
These files are used for mapping flags, definitions, and locations
into the overlay libraries and supplemental libraries.
This adds install commands for the object libraries contributing to
libswiftCore so that they are represented in SwiftCoreTargets.cmake.
Object libraries do not contribute anything to the files actually
installed.
`__progname` is not available on Windows, and is provided by libbsd on
Linux. This provides a replacement for the functional aspect of the
symbol on Windows.
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.
`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.
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.
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]`.
The swiftRuntime library is a C++/ObjC++ library. There is no need to
check the compile language for the additional flags allowing us to
simplify the call.
When building the standard library statically on Windows, we should not
use any __declspec(dllimport) or __declspec(dllexport) on the runtime
functions or data. Furthermore, we should internalise all of the
standard library functions so that they are not re-exported if used to
build a shared library. The code generation changes required for this
are easier to identify once a static SDK is available for Windows.
This matches the behavior introduced with #30733 -- quoting the
explanation here for the sake of convenience:
> Since libDemangling is included in the Swift standard library,
> ODR violations can occur on platforms that allow statically
> linking stdlib if Swift code is linked with other compiler
> libraries that also transitively pull in libDemangling, and if
> the stdlib version and compiler version do not match exactly
> (even down to commit drift between releases). This lets the
> runtime conditionally segregate its copies of the libDemangling
> symbols from those in the compiler using an inline namespace
> without affecting usage throughout source.
Addresses rdar://142550635
This hooks up the SWIFT_STDLIB_HAS_FILESYSTEM, which then requires
setting SWIFT_ARCH and SWIFT_LIB_SUBDIR macros for the backtracer.
Note: `FILESYSTEM` in this case does not refer to the C++ filesystem
header, but whether the platform you're building for has a filesystem.
Parts of the runtime depend on DLADDR/DLSYM. Use CMake to determine if
these functions are available and then define the
`SWIFT_STDLIB_HAS_DLADDR`/`SWIFT_STDLIB_HAS_DLSYM` when the function is
available.
`SWIFT_STDLIB_HAS_DLADDR` is used in several source files in the runtime
library. `SWIFT_STDLIB_HAS_DLSYM` only appears to be used in
`ThreadSanitizer.cpp`.
This define is meant to be present only when performing a build of a
dynamic library. The general pattern for this is:
```c
#if defined(LIBRARY_STATIC)
# define LIBRARY_ABI /**/
#else
# if defined(_WIN32)
# if defined(LIBRARY_EXPORTS)
# define LIBRARY_ABI __declspec(dllexport)
# else
# define LIBRARY_ABI __declspec(dllimport)
# endif
# elseif defined(__linux__) && !defined(__ANDROID__)
# define LIBRARY_ABI __attribute__((__visibility__("protected")))
# else
# define LIBRARY_ABI __attribute__((__visibility__("default")))
# endif
#endif
```
For AIX this would require an additional flag to be specified
(`-mdefault-visibility-export-mapping=explicit`). The same applies for
other non-AIX, non-Windows platforms with a different set of flags:
`-fvisibility=hidden -fvisibility-inlines-hidden`.
This is required to start trying to build the standard library
statically on Windows (which also requires further changes to the
Swift compiler).
Making a more in-depth pass over the definition macros and flags in
SwiftSource.cmake _add_target_variant_swift_compile_flags.
These are only flags that actually matter for swiftCore though. This
does not include concurrency flags.
De-duping some of the definitions. We can pass most of the definitions
to both the Swift and C/C++ compilers in the same form if we don't
assign anything. C/C++ will set the macro value to `1` if there is no
`=` as part of the definition, and `#if` recognizes a non-existent macro
to be false. With this logic, we can unify some of these.
This patch hooks up the swiftCore library build and gets it installing.
This means that we have library evolution hooked up and vector types.
Building it dynamically found that we had duplicate symbols, so fixed
the swiftDemanglingCR library.
Needed to hook up the availability macros.
The flag configuration is for macOS, so we'll need to go through and
figure out what it should look like for the other platforms too.
