`__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.
