When building a shared library on Windows, ensure that we export the
symbols. We would previously export none of the interfaces making the
dynamic library unusable. Simplify the macros as
`swiftRemoteMirror_EXPORTS` would only be defined when building a shared
library.
This extracts the version number computation out into a separate module
to be shared between the runtimes.
Setting `SWIFT_RUNTIME_VERSION` allows external build orchestration
tools to override the version number specified in source if necessary,
while centralizing the location of the default version number across the
runtime libraries.
Use the associated library name for the `CFBundleIdentifier` within the
plist. This will prevent cases where we have projects with multiple
targets referencing the project name itself (i.e swiftSwiftOnoneSupport
had it's bundle name set to SwiftCore)
This fixes modularization errors that arise when importing a C++ header that contains `#include <guiddef.h>`, which might hijack this header from the WinSDK module where it belongs.
Ensure that there are no undefined symbols at link time to validate that
we fully specified dependencies. This is the default behaviour on
Windows, but ELF targets will simply make any undefined symbols weakly
defined and rely on load time symbolic resolution.
Ensure that we always enable `-whole-module-optimization` as otherwise
we see library calls (e.g. `__atomic_load`) rather than the expected
inlined operation.
At the same time, drop that dependency in the new build system, so that
we don't add an additional linkage for Darwin platforms compared to what
we are doing in the current build system.
Addresses rdar://158314427
At the same time, drop that dependency in the new build system, so that
we don't add an additional linkage for Darwin platforms compared to what
we are doing in the current build system.
Addresses rdar://158313871
Piggyback the addition of a flag to specify the path of the
CMakeConfig.h header needed to compile Observation (needed when
consuming SwiftCore through the fine module), and the declaration of
SwiftShims as a dependency.
Addresses rdar://149241712
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 extracts the C++ runtime detection as recommended by Ben Boeckel.
Detect if `__GLIBCXX__` is defined in `<version>` indicating that
libstdc++ is being used. This allows for building the overlay for
alternative C++ runtimes (e.g. libc++) on Linux.
This introduces a build of the C++ interop runtime support to the new runtime library build.
Co-authored-by: Eric Miotto <1094986+edymtt@users.noreply.github.com>
This is required to ensure that we do not get ODR violations due to
LLVMSupport being linked in with multiple definitions. We would
previously miscompile the library resulting in a mixed signature
containing both `__swift::runtime::llvm::` and `::llvm::` versions of
`StringRef`.
Introduce a new runtimes build for the `_Volatile` module. This should
hopefully be the final supplemental library that we need for the
completion of the SDK.
We were not copying over the `Info.plist` and had checked in the file in
a few of the supplemental libraries. Update this now to follow the
proper behaviour.
Treat linker warnings as errors. This is to ensure that we do not
accidentally leak LNK4217 warnings which indicate miscompilation into
the runtimes. I thought that we had worked through them all, however,
one has seemed to have slipped through. The last remaining one is the
`_fatalErrorForwardModeDifferentiationDisabled` from the
`_Differentiation` module. This is incorrectly being marked as DLL
import:
```
LINK : warning LNK4217: symbol '_fatalErrorForwardModeDifferentiationDisabled' defined in 'DifferentiationUtilities-63c1ad.o' is imported by 'SIMDDifferentiation-e793ad.o' in function '$ss5SIMD2VyxSicisSBRzs10SIMDScalarRz16_Differentiation14DifferentiableRz13TangentVectorAdEPQzRszlTJfSUSpSr'
LINK : warning LNK4286: symbol '_fatalErrorForwardModeDifferentiationDisabled' defined in 'DifferentiationUtilities-63c1ad.o' is imported by 'FloatingPointDifferentiation-557cd1.o'
```
This fixes up the Android builds to properly link against the right
modules. With this we properly propagate the necessary flags to build
the runtimes without colliding with existing builds.
Setup the interface include directory that seems to not be setup
implicitly by CMake as it should be. This workaround is necessary to
ensure that we are able to build against this module.
When building against the build tree, we need to ensure that the flags
for the ClangModule propagate. This is required to ensure that we get
the modules visible even when building the rest of the SDK.
We concatenated the path without consideration for the path separator as
the path separator was expected to be present. This is not guaranteed.
Explicitly add the missing separator which is required to construct the
proper path.
When building against the build tree, we need to ensure that the flags
for the ClangModule propagate. This is required to ensure that we get
the modules visible even when building the rest of the SDK.
