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.
Default system linkers on non-Darwin platforms do not support the `-framework`
argument for framework linking. This change updates autolinking to not emit
`-framework` into the .o _swift1_autolink_entries metadata when there is no
native linker support.
This is related to rdar://106578342.
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
Two tests used -emit-library with the same module name and without an
explicit -o path, meaning that the output would go into whatever
lit.py was using as its working directory. If the tests ran at exactly
the same time, they could contend for the output file. We don't actually
use the built library at all in the test, so just drop the -emit-library
entirely.
Also, remove an unused compilation step from another test, which just
checks what happens when swift-autolink-extract doesn't use any
arguments.
rdar://problem/39510413
Cygwin and MinGW should use the autolink feature in the sameway of Linux
due to the linker's limit. Now swift-autolink-extract recognizes the
COFF format file for Cygwin/MinGW.
Rather than relying on the system to provide ar and nm, use the LLVM equivalent
tools instead. Since the build is already dependent on llvm and its tools, this
just ensures that the full set is self-contained. NFC.
Previously it just gave up when it saw anything other than an ELF .o file. We
could have it ignore .a files, but we might as well do the right thing.
<rdar://problem/23045632>
