| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SwiftMixLib test was failing on Windows due to a missing link
against swiftCore. On macOS and Linux, there are mechanisms for
extracting the libraries that the object depends on and passing that to
the linker so that the library dependencies don't need to be listed
explicitly. The Windows Swift toolchain does not have this mechanism.
In the future, it would likely make sense for CMake to pass some of the
implicitly required libraries for linking Swift via
`CMAKE_Swift_IMPLICIT_LINK_LIBRARIES`. Unlike the normal mechanisms
though, these libraries would need to be passed even when the link
language is Swift.
For now though, we should get the test up and running again.
Fixes: #25573
|
| |
|
|
|
|
|
|
| |
Swift on Windows provides only a release runtime.
Use it for C and CXX too, in all configurations, to match.
Issue: #25573
Suggested-by: Saleem Abdulrasool <compnerd@compnerd.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Swift is used as the linker for non-swift files because it needs to pull
files like swiftrt.o in when swift symbols are present to ensure that
the swift runtime is linked.
The swift driver uses clang as the underlying linker, which pulls in
crtbegin.o and friends when appropriate, so using Swift as a linker for
C/C++ libraries is fine.
The output-file-map was getting passed to all Swift invocations,
regardless of whether or not we generated one. This patch changes it so
that we only include the output-file-map in the Swift compiler
invocation if we have actually generated the file.
|
|
|
This test ensures we can configure and build mixed source binaries. The
test configures, but fails to verify due to multiple targets emitting
the `lib.c.o` and `lib.cpp.o` outputs. Both the clang build step and the
swift link step report that they emit the `lib.c.o` and `lib.cpp.o`
outputs. The `.o`'s are emitted by clang, not by swift.
|
