- If --build-swift-static-stdlib option is used then also produce
static versions of libXCTest.a and libdispatch.a and put them
into the lib/swift_static/linux/ toolchain directory.
libFoundation.a is already being built and deployed there.
- Binaries with the swift libs statically linked in can then be
built with using the command:
swift build -Xswiftc -static-stdlib -Xlinker -lcurl -Xlinker -l:libxml2.a -Xlinker -llzma -Xlinker /lib/x86_64-linux-gnu/libz.so.1 -Xlinker -lbsd -Xlinker --allow-multiple-definition
Note: This is a dynamic binary with the libswiftCore,
libFoundation and libdispatch libraries statically linked in.
- Further fixes should reduce the complexity of the above command.
Before Swift 3.1, we installed the swift-stdlib-tool-substitute script
in place of Xcode's swift-stdlib-tool. This check was added to the build
script (76e99159c1) to avoid trying to strip that file. Now that
swift-stdlib-tool is part of open-source Swift, the -substitute script is
gone and there is no need for this check.
Fix the mocked output files of swiftc. Change the lookup of
clang from build-script to build-script-impl like all the other
commands. Pass more args to LLVM. Fix swiftenv creation. Fix unit tests.
The reason this patch works is that build-script-impl gets
all the arguments that are not handled by build-script.
When moving to the swift-4.0-branch of LLVM, we started using the
LLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING cmake option to turn off those
checks. This was necessary for the stdlib build, where it uses some LLVM
headers without linking libSupport.a, but the cmake option forced us to
disable the checks across the board. It also caused a lot of churn for
people who needed to remove their cmake caches when switching to the new
version of LLVM. This change switches to use a preprocessor macro to
disable the checks only in the context of the stdlib build. It requires
LLVM r295090. rdar://problem/30098953
Fixed for the difference of Cygwin with other Windows variants (MSVC,
Itanium, MinGW).
- The platform name is renamed to "cygwin" from "windows" which is used
for searching the standard libraries.
- The consideration for DLL storage class (DllExport/DllImport) is not
required for Cygwin and MinGW. There is no problem when linking in
these environment.
- Cygwin should use large memory model as default.(This may be changed
if someone ports to 32bit)
- Cygwin and MinGW should use the autolink feature in the sameway of
Linux due to the linker's limit.
If cmake is run on another machine, the default Xcode path and
more in the cmake cache and ninja files will be of that machine's
configuration, not the local machine's.
Test with:
./utils/build-script -r -- --distcc --verbose
The cmake lines should start with ``/usr/local/bin/cmake`` instead of with
``/opt/distcc/pump``.
rdar://problem/29942258
