Autolinking was added to the frontend in 22912bc3b. It was disabled on
Linux in 198402dcf, and further constrained to be disabled on "linux-gnu"
in 83b4384fa. Since then, more flavors of Linux have become supported
by Swift: "linux-gnueabihf" in 4bf81e09d, and "freebsd" in f41b791d4.
Autolinking most likely does not work on any of these platforms, so
mark it as unsupported for now.
Other tests that only mark "linux-gnu" as unsupported do so for similar
reasons. Ensure unsupported tests for "linux-gnu" are also unsupported
on similar platforms.
As suggested by John. This results in the symbols being coalesced at static
link time into a single strong symbol in a built dylib. Fortunately we don't
care about the contents of these global symbols, so common linkage's
forced zero-initialization is fine. (Hey, C's tentative definitions are
useful for something after all.)
rdar://problem/20072051
Swift SVN r25804
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Refuse to load a module if it was compiled for a different architecture or
OS, or if its minimum deployment target is newer than the current target.
Additionally, provide the target triple as part of pre-loading validation
for clients who care (like LLDB).
Part of rdar://problem/17670778
Swift SVN r24469
