-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Build] Add the new fully-static Linux SDK. #71839
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This sits on top of #71838. |
@swift-ci Please smoke test |
@swift-ci Please smoke test |
baa2d02
to
ee69cbc
Compare
@swift-ci Please smoke test |
ee69cbc
to
6b8467a
Compare
6b8467a
to
8ee2fe6
Compare
@swift-ci Please smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The overall approach looks good, given the moderate size I did a first pass with my initial impressions -- loosely wondering if there is a way to break this PR in smaller chunks (e.g. land first the plumbing of the build-script args, and leave last the more substantial changes to the CMake logic that may require more discussion).
@@ -351,6 +352,36 @@ def build(self, host_target): | |||
llvm_cmake_options.define('LLVM_INCLUDE_TESTS', 'NO') | |||
llvm_cmake_options.define('CLANG_INCLUDE_TESTS', 'NO') | |||
|
|||
build_root = os.path.dirname(self.build_dir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of these cfg
files? Are those needed only when targeting the static Linux SDK in build-script, or they need to be present in the generated toolchains?
Trying to understand if these need to be generated regardless for every platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will want them in the generated toolchains, but they are also required for the build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need then to invoke this logic in the install
method as well? Leaning toward yes given your previous reply.
Do we need to gate such logic behind args.build_swift_static
? Wondering if e.g. we want to always install it (so the generated toolchain can used to build the static stdlib), but generate in the build folder only if we are building the static library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm slightly torn about this; I had intended to get rid of the .cfg
files by patching the compiler drivers, particularly now I've changed the triple to a special one for the static SDK (<arch>-swift-linux-musl
instead of <arch>-unknown-linux-musl
). I think though that we probably do want to add them in the install phase for now; we can always remove them again later if it's a problem.
Declare a new `LINUX_STATIC` SDK and configure it. Add options to set the build architectures for the `LINUX` and `LINUX_STATIC` SDKs, similar to what we have for Darwin, because we'll be cross-compiling. Also add an option to point the build system at the sources for the musl C library, which we're using for `LINUX_STATIC`. rdar://123503470
Change the `--linux[-static]-arch` option to `--linux[-static]-archs`, on the basis that it supports multiple values. Other tidying. rdar://123503470
Apparently I accidentally removed a `]` while resolving a conflict in `build_script_invocation.py.` rdar://123503470
The Python linter was complaining about import orders. rdar://123503470
Apparently I'd failed to add a couple of lines here. rdar://123503470
@swift-ci Please smoke test |
utils/swift_build_support/swift_build_support/build_script_invocation.py
Show resolved
Hide resolved
@@ -351,6 +352,36 @@ def build(self, host_target): | |||
llvm_cmake_options.define('LLVM_INCLUDE_TESTS', 'NO') | |||
llvm_cmake_options.define('CLANG_INCLUDE_TESTS', 'NO') | |||
|
|||
build_root = os.path.dirname(self.build_dir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need then to invoke this logic in the install
method as well? Leaning toward yes given your previous reply.
Do we need to gate such logic behind args.build_swift_static
? Wondering if e.g. we want to always install it (so the generated toolchain can used to build the static stdlib), but generate in the build folder only if we are building the static library.
Fix some indentation issues. Change `build-script-impl` to make `build-linux-static` a positive argument. Fix documentation for `--linux-archs` and `--linux-static-archs` (the options are comma separated for `build-script`, but semicolon separated for `build-script-impl`). Set the default for `linux-static-archs` to `x86_64, aarch64` so that we install the expected content in the toolchain. Add missing default for `test_linux_static`. Make sure to pass down `--skip-build-linux` and `--build-linux-static`. Factor out config file generation and call it from the install step in `llvm.py` as well as from the build step. rdar://123503470
@swift-ci Please smoke test |
Remove unused import of `importlib.resources`. Set `test_linux_static` to `False` if tests are disabled. rdar://123503470
@swift-ci Please smoke test |
@swift-ci test webassembly |
Failures are:
because
(similar error on macOS). Not sure this is to do with this PR; looking into it now. |
|
@swift-ci Please smoke test |
Hmmm. It's failing because it can't find |
@swift-ci Please smoke test |
@swift-ci Please smoke test |
`TypeRoundTrip/round-trip.swift` tries to link with `libswiftRemoteInspection`, but that library isn't in the default link path, so we need to add a `-L` option to the command line in the test. Also, we should check that `SWIFT_BUILD_REMOTE_MIRROR` is enabled and disable the test if not, because otherwise `libswiftRemoteInspection` won't have been built. rdar://123503470
@swift-ci Please smoke test |
The problem was that |
Looks like I'd unconditionally added -lfts to the Foundation build flags. rdar://123503470
@swift-ci Please smoke test |
@swift-ci Please smoke test Linux platform |
(The previous failure was because the integration tests tried to treat the |
[Build] Add the new fully-static Linux SDK.
This was added by swiftlang#71839 as part of a fix for the `TypeRoundTrip/round-trip.swift` test, but it isn't necessary and it's breaking nightly builds. rdar://128000843
This was added by swiftlang#71839 as part of a fix for the `TypeRoundTrip/round-trip.swift` test, but it isn't necessary and it's breaking nightly builds. rdar://128000843
Declare a new
LINUX_STATIC
SDK and configure it.Add options to set the build architectures for the
LINUX
andLINUX_STATIC
SDKs, similar to what we have for Darwin, because we'll be cross-compiling.Also add an option to point the build system at the sources for the musl C library, which we're using for
LINUX_STATIC
.rdar://123503470