Add a new bits/ header to the Android overlay, include runtime libraries that are
auto-extracted and listed many times to the list of libraries to be de-duplicated,
enable a C++ interop test that's working again, and update the doc with new
libraries that need to be available to run a simple executable.
In Linux, the current implementation of swift-autolink-extract does not
support LLVM IR files resulting from using LTO.
If one tries to build LLVM using LTO and then try to link one of the
targets that use `swiftc` to link, but link against LLVM object files
(like `swift-plugin-server`), `swift-autolink-extract` will fail saying
that some object files are not valid.
To deal with LLVM IR files correctly, create and pass
a `llvm::LLVMContext` around, which allows the APIs in `llvm::object` to
read LLVM IR files. Additionally, handle the case of `IRObjectFile` when
extracting, but perform no action.
Once the API has gone through Swift Evolution, we will want to implicitly
import the _Backtracing module. Add code to do that, but set it to off
by default for now.
rdar://105394140
We cannot filter all libraries because duplicate -l flags have a semantic meaning based on their order, but filtering out just the common Swift libraries should yield a good size improvement already and is safe.
Otherwise we can duplicate linker flags across input binaries, which can result in very large linkerr invocation commands.
Resolves https://github.com/apple/swift/issues/58380
This change adds support for `.swift1_autolink_entries` in WebAssembly object files to `lib/DriverTool/autolink_extract_main.cpp`. This is implemented in a similar way to existing ELF autolink entries handling.
