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>
