TBD generation is not constrained to Darwin and it trips on the linker
synthetic `__ImageBase`. XFAIL this until the TBD generation is either
constrained or is taught to ignore the synthetic. This should
temporarily allow us to enable validation tests on Windows.
This just uses the `%target-build-swift-dylib` instead of
`%target-build-swift` substitution along with `%target-library-name` to
ensure that we are target independent.
The naming convention is different on Windows than on Unix-like
environments. In order to follow the convention we need to substitute
the prefix and the suffix. Take the opportunity to rename the
`target-dylib-extension` to the CMake-like variable
`target-shared-library-suffix` and introduce
`target-shared-library-prefix`. This helps linking the test suite
binaries on Windows.
Most of this is just "remember to specify the inputs and outputs on
the command line, so remote-run can see them". A bit is "prefix
environment variables with '%env-'". And the last few are "yeah,
this was never going to work in a remote environment".
In the few cases where I couldn't think of anything reasonable, I just
marked the test as "UNSUPPORTED: remote_run", a new "feature".
Investigating a problem with execution tests on other platforms
when building multiple dylibs and an executable that builds them.
rdar://problem/27620565
There wasn't an execution test involving #dsohandle, so add one here.
Also, the DSO handle coming from different modules should never be
the same.
rdar://problem/26565092
