[build] Add the flags to enable cross-compiling the corelibs #33724

finagolfin · 2020-08-31T20:27:02Z

Pass the Swift and CMake flags needed to cross-compile Foundation and so on, with the first example of Android AArch64. Add a new flag, --cross-compile-deps-path, which is used to search for cross-compiled libraries, like libcurl, that the corelibs depend on.

This would be useful both for building cross-compilation SDKs and building native SDKs faster for some slow platforms, like the Raspberry Pi.

I've been using an earlier version of this patch for the last couple months to cross-compile a native Android toolchain from linux x86_64, termux/termux-packages#5352. After unpacking the Aug. 18 trunk snapshot of the Swift toolchain for Ubuntu 20.04 and the Termux Android binary packages for libcurl and so on into /data/data/com.termux/files/usr, I ran the following command to compile the Swift stdlib and corelibs both natively for linux x86_64 and for Android AArch64 (without this pull applied, the build-script will simply build the corelibs for the linux host twice):

./swift/utils/build-script -R --no-assertions --skip-build-llvm
--android --android-ndk /home/butta/android-ndk-r21d/
--android-arch aarch64 --android-api-level 24
--android-icu-uc /data/data/com.termux/files/usr/lib/libicuuc.so
--android-icu-uc-include /data/data/com.termux/files/usr/include/
--android-icu-i18n /data/data/com.termux/files/usr/lib/libicui18n.so
--android-icu-i18n-include /data/data/com.termux/files/usr/include/
--android-icu-data /data/data/com.termux/files/usr/lib/libicudata.so
--build-swift-tools=0 --native-swift-tools-path=/home/butta/swift-818/usr/bin
--native-llvm-tools-path=/home/butta/swift-818/usr/bin
--native-clang-tools-path=/home/butta/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin
--host-cc=/home/butta/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
--host-cxx=/home/butta/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
--build-runtime-with-host-compiler --cross-compile-hosts=android-aarch64
--cross-compile-deps-path=/data/data/com.termux/files/usr
--xctest -b --install-swift --install-libdispatch --install-foundation
--install-xctest

The last three redundant clang paths were needed because otherwise two different clangs could be passed to CMake when cross-compiling the corelibs, which confuses and breaks the CMake configuration. This invocation makes sure only one clang is used. The problem is that --host-cc is a Python build-script flag while --native-clang-tools-path is a bash build-script-impl flag: I'll look into pulling them all into the Python build-script later.

I tested the above Android SDK with Foundation and another corelibs example by cross-compiling these small executables like this:

/home/butta/swift-818/usr/bin/swiftc -target aarch64-unknown-linux-android
-resource-dir /home/butta/swift/build/Ninja-Release/toolchain-linux-x86_64/android-aarch64/usr/lib/swift
-sdk /home/butta/android-ndk-r21d/platforms/android-24/arch-arm64
-tools-directory /home/butta/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin
-Xcc -I/home/butta/android-ndk-r21d/sysroot/usr/include
-Xcc -I/home/butta/android-ndk-r21d/sysroot/usr/include/aarch64-linux-android
foundationExample.swift

After transferring these executables to an Android AArch64 device and running them with LD_LIBRARY_PATH set to a local copy of the corelibs, everything ran fine. I've also been using these cross-compiled corelibs to cross-compile the Swift package manager in a separate patch and that's been working well, so it works for larger builds too.

@shahmishal, this may be useful to cross-compile for the new Apple Silicon too, at least for those Swift projects that can be built on macOS at all.

gottesmm · 2020-09-01T22:48:26Z

Just looking through and beginning to understand this patch. I am hesitant in general to add support to build-script-impl. Especially the cross-compiled part of build-script-impl which is the least well tested out. I need to look/think about this in more detail.

gottesmm · 2020-09-01T22:50:24Z

utils/build-script-impl

@@ -2217,6 +2282,9 @@ for host in "${ALL_HOSTS[@]}"; do
                    -DENABLE_TESTING=YES
                    -DBUILD_SHARED_LIBS=$([[ ${product} == libdispatch_static ]] && echo "NO" || echo "YES")
                  )
+                  if [[ $(is_cross_tools_host ${host}) ]] ; then
+                      add_cross_cmake_options ${host} cmake_options


This is the first time that we are using CMake cross compilation under the hood in build-script-impl. I wonder if it would make sense to always cross compile everything in build-script-impl. I don't know how much work that would entail, but it is work that would need to be done. Especially since @shahmishal is going to need to fix the cross compilation loop for build-script products.

What do you mean by "cross-compile everything," explicitly pass in all these compiler and sysroot flags when natively compiling too? That might make sense, but as you said, would be a fair amount of work to track them all down. Of course, the benefit is that every natively supported platform becomes easily cross-compilable from other platforms.

As for fixing "the cross compilation loop for build-script products," I have a pull forthcoming with the tweaks I had to make to build-script when cross-compiling SPM, as that's a build-script product not built here in build-script-impl.

finagolfin · 2020-09-02T08:30:13Z

I am hesitant in general to add support to build-script-impl.

Thinking about this some more, I have a pull in the works to cross-compile SPM too, which is built by build-script, and I could translate these two new bash functions common_swift_flags() and add_cross_cmake_options() to be on the Python build-script side instead, so they could be used for both.

Of course, the remaining parts of this pull would have to stay in this bash script, as that's the only way to configure the corelibs.

finagolfin · 2020-12-01T16:17:56Z

Alright, made the changes discussed above, all split off into a separate commit so it's easy to see what changed. Applying this pull and the related pulls #34491 and #34628, which are not strictly necessary for this one but allow me to use the unified sysroot here and elide one flag, I was able to build a functional Android SDK with the Nov. 26 source snapshot and the official prebuilt trunk snapshot of the linux toolchain, by running this command:

./swift/utils/build-script -R --no-assertions --skip-build-cmark --build-llvm=0 --android
--android-ndk /home/butta/swift/android-ndk-r21d/ --android-arch aarch64 --android-api-level 24
--android-icu-uc /home/butta/swift/swift-android-aarch64-24-sdk/usr/lib/libicuuc.so
--android-icu-uc-include /home/butta/swift/swift-android-aarch64-24-sdk/usr/include/
--android-icu-i18n /home/butta/swift/swift-android-aarch64-24-sdk/usr/lib/libicui18n.so
--android-icu-i18n-include /home/butta/swift/swift-android-aarch64-24-sdk/usr/include/
--android-icu-data /home/butta/swift/swift-android-aarch64-24-sdk/usr/lib/libicudata.so --build-swift-tools=0
--native-swift-tools-path=/home/butta/swift/swift-DEVELOPMENT-SNAPSHOT-2020-11-26-a-ubuntu20.04/usr/bin/
--native-clang-tools-path=/home/butta/swift/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin
--host-cc=/home/butta/swift/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
--host-cxx=/home/butta/swift/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
--cross-compile-hosts=android-aarch64 --cross-compile-deps-path=/home/butta/swift/swift-android-aarch64-24-sdk
--swift-install-components='clang-builtin-headers;license;stdlib;sdk-overlay'
--install-swift --install-libdispatch --install-foundation --install-xctest --xctest --skip-local-build -j9

I was then able to cross-compile Swift packages like swift-argument-parser and their tests for Android with this JSON config

{
    "version": 1,
    "target": "aarch64-unknown-linux-android",
    "toolchain-bin-dir": "/home/butta/swift/swift-DEVELOPMENT-SNAPSHOT-2020-11-26-a-ubuntu20.04/usr/bin",
    "sdk": "/home/butta/swift/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot",
    "extra-cc-flags": [
        "-fPIC"
    ],
    "extra-swiftc-flags": [
        "-resource-dir", "/home/butta/swift/build/Ninja-Release/toolchain-linux-x86_64/android-aarch64/usr/lib/swift",
        "-tools-directory", "/home/butta/swift/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin",
        "-Xclang-linker", "--target=aarch64-linux-android24",
        "-L/home/butta/swift/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/lib/gcc/aarch64-linux-android/4.9.x",
    ],
    "extra-cpp-flags": [
        "-lstdc++"
    ]
}

by passing it in to the linux SPM like so:

~/swift/swift-DEVELOPMENT-SNAPSHOT-2020-11-26-a-ubuntu20.04/usr/bin/swift build --build-tests --destination ~/android-aarch64.json

The directory swift-android-aarch64-24-sdk/ used to build the SDK simply contains some cross-compiled libraries and headers that the stdlib and corelibs depend on, such as libicu and libcurl. I detail how I put that together using prebuilt Termux packages elsewhere.

While these commands produce a working SDK, further patchelf commands will need to be run to set some of their rpaths properly before running them on Android.

@drodriguez, once this is in, you could expand the Android CI to build the corelibs and some Swift packages if you like, rather than only cross-compiling the stdlib as it does now.

finagolfin · 2020-12-01T16:24:18Z

CMakeLists.txt

@@ -435,7 +435,7 @@ option(SWIFT_BUILD_ONLY_SYNTAXPARSERLIB "Only build the Swift Syntax Parser libr
 option(SWIFT_BUILD_SOURCEKIT "Build SourceKit" TRUE)
 option(SWIFT_ENABLE_SOURCEKIT_TESTS "Enable running SourceKit tests" ${SWIFT_BUILD_SOURCEKIT})

-if(SWIFT_BUILD_SYNTAXPARSERLIB OR SWIFT_BUILD_SOURCEKIT)
+if(SWIFT_INCLUDE_TOOLS AND (SWIFT_BUILD_SYNTAXPARSERLIB OR SWIFT_BUILD_SOURCEKIT))


This libdispatch build is only needed for these host tools and I got sick of the standalone stdlib unnecessarily building it, so I disabled it in that scenario.

finagolfin · 2020-12-01T16:25:14Z

utils/build-script

@@ -795,6 +795,7 @@ class BuildScriptInvocation(object):
        """

        args = self.args
+        args.build_root = self.workspace.build_root


I need this later in the new swift_flags() method.

finagolfin · 2020-12-01T16:36:06Z

utils/build-script-impl

@@ -222,6 +221,7 @@ KNOWN_SETTINGS=(
    cross-compile-hosts                           ""                "space-separated list of targets to cross-compile host Swift tools for"
    cross-compile-with-host-tools                 ""                "set to use the clang we build for the host to then build the cross-compile hosts"
    cross-compile-install-prefixes                ""                "semicolon-separated list of install prefixes to use for the cross-compiled hosts. The list expands, so if there are more cross-compile hosts than prefixes, unmatched hosts use the last prefix in the list"
+    cross-compile-deps-path                       ""                "path for CMake to look for cross-compiled library dependencies, such as libXML2"


I thought about making this a list like cross-compile-hosts but realistically only one cross-compilation host is ever passed in, so this will do for now. The issue is that each cross-compilation host will require its own separate C/C++ cross-compilation toolchain, which there's no way to pass in to build-script yet. We're able to handle a single cross-compilation host with hacked-in flags like --android-ndk and --native-clang-tools-path, but for example, we can't even build multiple Android architectures with a single build-script invocation yet.

@buttaface I think the last sentence is incorrect. I imagine that if one hacked in something similar to what we have on Darwin in the stdlib cmake (which is horrible btw and I am not suggesting this).

That being said, shouldn't this just be found in some notion of an SDK? I think that is how on Darwin this would work.

The reason I said "we can't even build multiple Android architectures with a single build-script invocation yet" in my last sentence is that, for example, we pass in the path to a particular libicu built for one arch when invoking build-script. Even on Darwin, only compiling the Swift compiler itself for macOS x86_64 was supported until recently, when support for cross-compiling it from macOS x86_64 to arm64 was added but not the other way, swiftlang/swift-package-manager#3500, but again only a single cross-compilation host is supported on Darwin. Of course, one could hack in further changes to support multiple hosts, but it is currently not supported.

As for this just being an SDK, it is more general than that. I use this flag below to find dependencies like libxml2 or libsqlite3, which are additional package dependencies that aren't usually included in cross-compilation SDKs. I found this useful when cross-compiling the toolchain for Android, as I pass in the Termux prefix with those prebuilt library packages installed to this flag and the separate Android NDK, that has the libc sysroot but no libraries like libxml2, to the --android-ndk flag above.

This gives the most flexibility because if they are all in one SDK, you can always pass the same SDK path in to both flags.

finagolfin · 2020-12-01T17:02:14Z

utils/swift_build_support/swift_build_support/host_specific_configuration.py

+            if deployment_target_name != args.host_target and \
+                host_target != args.host_target:
+                self.swift_flags = deployment_target.swift_flags(args)
+                self.cmake_options = deployment_target.cmake_options(args)


Note that I didn't name these Python functions with cross or anything else related to cross-compilation like I had the bash functions in the first commit, so that if you ever want to use them for native compilation too, just remove these two checks above and go.

finagolfin · 2020-12-03T03:26:03Z

Added a last two-line commit that provides a build-script-impl flag to pass in Swift flags to the corelibs. Saleem pointed out that adding CMAKE_Swift_FLAGS in the build script precludes passing it in with one of the *-cmake-options variables, so this provides a way to pass in common flags.

For example, I mentioned earlier needing to patchelf the corelibs rpaths, but I was able to pass it in with this flag instead, --common-swift-flags="-Xlinker -rpath -Xlinker \\\$\$ORIGIN/../..". If there's a need later for passing in flags for each individual project, like the current --libdispatch-cmake-options flag, we could add that later.

@compnerd, let me know if this addresses your concerns, as CMAKE_Swift_FLAGS has since been added to build-script-impl by #34728.

finagolfin · 2020-12-09T16:28:24Z

@CodaFi, could you take a look at this pull? I'd like to get it in before the 5.4 branch, but I think Michael is busy with his ownership work.

finagolfin · 2021-05-27T09:07:12Z

@varungandhi-apple, mind running the CI on this? I just talked to @gottesmm and it looks like we can move forward on this, as I'd like to get it into the 5.5 branch.

gottesmm

This is almost there. Please respond to my comments. I need to think about a few things with this. But I think it is the right direction and has a very light touch overall.

CMakeLists.txt

gottesmm · 2021-05-30T03:14:31Z

utils/swift_build_support/swift_build_support/targets.py

+        options = ''
+        if self.platform.name == 'android':
+            options = '-DCMAKE_SYSTEM_NAME=Android '
+            options += '-DCMAKE_SYSTEM_VERSION=%s ' % (args.android_api_level)


Can you use the CMakeOptions() thing? The reason why is that I am going to be changing that to autogenerate Toolchain files and then I can just take what you already wrote here and it will just work.

(The plan is to make it so that we are always cross compiling with a toolchain).

Also this is platform specific so I wonder if we can refactor this out onto the Android platform.

I don't think so as CMakeOptions() is used to pass CMake flags in this Python build-script, whereas this is a string passed to the old bash build-script-impl. I suppose I could use CMakeOptions() to define these Android flags, then turn that Python list into a string again before passing it to build-script-impl, but we could always do that later once you move everything to CMake toolchain files. Just let me know what you prefer.

As for refactoring it above, will do.

I was thinking about this... I am fine with leaving it like this for now. But the refactoring I would like.

gottesmm · 2021-05-30T03:16:36Z

utils/swift_build_support/swift_build_support/targets.py

@@ -152,6 +152,34 @@ def __init__(self, platform, arch):
    def name(self):
        return "{}-{}".format(self.platform.name, self.arch)

+    def swift_flags(self, args, resource_dir_root=""):
+        flags = ''
+        if self.platform.name == 'android':


If this is specific to the android platform, can you add this as a helper on that class?

I changed these to methods on AndroidPlatform and ran the build again: only after it errored did I remember why I added these methods to this Target class instead, ie Target has an arch whereas Platform just has a list of possible arches. Since these flags are generated for a single architecture, I need to keep them here.

is it possible to pass this in to a method on platform... IDK. My worry here is that this will lead us to a build-script-impl world where we have a large if else depending on what we are building for?

Yes, but I would have to pass in the selected arch as a parameter to swift_flags(). I have that refactor patch lying around, so I will add the arch part and push it, then you can decide if it's what you want.

Made this change in latest commit.

utils/build-script-impl

gottesmm · 2021-05-30T03:28:55Z

utils/build-script-impl

@@ -222,6 +221,7 @@ KNOWN_SETTINGS=(
    cross-compile-hosts                           ""                "space-separated list of targets to cross-compile host Swift tools for"
    cross-compile-with-host-tools                 ""                "set to use the clang we build for the host to then build the cross-compile hosts"
    cross-compile-install-prefixes                ""                "semicolon-separated list of install prefixes to use for the cross-compiled hosts. The list expands, so if there are more cross-compile hosts than prefixes, unmatched hosts use the last prefix in the list"
+    cross-compile-deps-path                       ""                "path for CMake to look for cross-compiled library dependencies, such as libXML2"


@buttaface I think the last sentence is incorrect. I imagine that if one hacked in something similar to what we have on Darwin in the stdlib cmake (which is horrible btw and I am not suggesting this).

That being said, shouldn't this just be found in some notion of an SDK? I think that is how on Darwin this would work.

gottesmm · 2021-05-30T03:32:34Z

utils/build-script-impl

-            )
-            ;;
-    esac
+    echo -n "${SWIFT_FLAGS[@]} -module-cache-path \"${module_cache}\" "


I can't remember if module_cache is expanded out or not. If it must be defined for this to work, please add an assert to make sure it is defined.

It will always be defined, because it is always set in the build loop for all products. I suppose now that I moved this to a function someone may later call it outside that build loop, say in the testing loop, though it is only called in the build loop now. If you're still worried about that, I can pass it in as a parameter to this function or add an assert.

just the assert would be useful. That way if someone messes up we get a nice error msg.

gottesmm · 2021-05-30T03:35:23Z

utils/swift_build_support/swift_build_support/host_specific_configuration.py

+            # --cross-compile-hosts.
+            if deployment_target_name != args.host_target and \
+                host_target != args.host_target:
+                self.swift_flags = deployment_target.swift_flags(args)


I really dislike how this mutates global state in self outside of self. I would feel more comfortable if there was an explicit method on self that takes in the deployment_target and sets flags. Something like that.

Not sure what you mean, as self in this case is HostSpecificConfiguration for which these lines I'm adding are in the initializer for that class. This is in keeping with how this initializer configures other variables like self.sdks_to_configure above.

I meant outside of the class. It seems like one could make a separate method that does this on self that way it is self contained and given a nice comment explaining that we are changing the deployment target or updating the deployment target.

gottesmm · 2021-05-30T03:36:26Z

Another thing that would be good is if one adds a few build system unit tests for build-script-impl to make sure things keep working as you expect.

drexin · 2021-06-26T01:40:17Z

@swift-ci test

swift-ci · 2021-06-26T03:16:23Z

Build failed
Swift Test OS X Platform
Git Sha - b523e76539e52801fcd67df611135ef463d482ac

finagolfin · 2021-06-26T03:32:01Z

Single Mac test failure is unrelated, and something unrelated appears broken on the Win CI.

drexin · 2021-06-26T05:30:07Z

@swift-ci test macos

drexin · 2021-06-26T05:30:18Z

@swift-ci test windows

swift-ci · 2021-06-26T07:03:54Z

Build failed
Swift Test OS X Platform
Git Sha - b523e76539e52801fcd67df611135ef463d482ac

finagolfin · 2021-06-26T09:04:11Z

Win CI passed, same test failing on Mac CI again. Looks like the Mac CI is broken right now, as this completely unrelated pull also shows the same test failing.

finagolfin · 2021-06-28T05:43:47Z

@drexin, Mac CI is fixed, would you run it for this pull again?

drexin · 2021-06-28T06:54:09Z

@swift-ci test macos

swift-ci · 2021-06-28T14:58:52Z

Build failed
Swift Test OS X Platform
Git Sha - b523e76539e52801fcd67df611135ef463d482ac

finagolfin · 2021-06-28T19:42:49Z

Sigh, macOS CI is broken again, latest Mac CI run for this pull fails for the same tests as this unrelated pull.

gottesmm · 2021-06-28T23:19:34Z

@swift-ci test macOS platform

finagolfin · 2021-06-29T01:00:18Z

Gah, this also failed the Python lint that is only run on the Mac CI, I will fix and push again.

swift-ci · 2021-06-29T01:06:01Z

Build failed
Swift Test OS X Platform
Git Sha - b523e76539e52801fcd67df611135ef463d482ac

Pass the Swift and CMake flags needed to cross-compile Foundation and so on, with the first example of Android. Add a new flag, --cross-compile-deps-path, which is used to search for cross-compiled libraries, like libcurl, that the corelibs depend on. Also add a new flag, --common-swift-flags, to pass additional Swift flags to the corelibs.

finagolfin · 2021-06-29T01:17:55Z

Alright, Mac CI stopped for some reason. I added the whitespace needed to pass the Python linter and squashed everything into one commit.

@drexin or @gottesmm, this should pass the CI now.

drexin · 2021-06-29T02:09:30Z

@swift-ci test

swift-ci · 2021-06-29T04:59:43Z

Build failed
Swift Test OS X Platform
Git Sha - a4ff4db

finagolfin · 2021-06-29T05:41:44Z

Some unrelated issue with SwiftSyntax on the Mac CI, hit this completely different pull too.

finagolfin · 2021-06-29T23:03:19Z

@drexin, looks like the Mac CI is running again, would you trigger that one again?

drexin · 2021-06-29T23:03:55Z

@swift-ci test macos

finagolfin · 2021-06-30T04:18:07Z

Passed CI, ready for merge.

shahmishal · 2021-06-30T19:15:23Z

10:40:38 Failed Tests (1):
10:40:38   Swift(macosx-arm64) :: BuildSystem/android_cross_compile.test

https://ci.swift.org/job/oss-swift-incremental-RA-macos-apple-silicon/966/console

@buttaface We are seeing this failure on Apple Silicon, is it ok to disable this test for macOS platforms?

finagolfin · 2021-06-30T21:03:44Z

@shahmishal, I will submit a pull to disable it for macos-arm64 in 15 min, as I don't know what's going wrong there.

gottesmm reviewed Sep 1, 2020

View reviewed changes

finagolfin force-pushed the core branch from 5fa1d36 to 79d7e96 Compare September 25, 2020 17:38

finagolfin changed the base branch from master to main September 25, 2020 17:38

This was referenced Oct 27, 2020

When building standalone stdlib, use Clang resource dir from the toolchain, not the system default #33675

Merged

[android] Move to the NDK's unified sysroot #34491

Merged

finagolfin mentioned this pull request Nov 10, 2020

[android] Add support for x86_64 arch #34661

Merged

finagolfin force-pushed the core branch 2 times, most recently from 7ee1c4d to ddd44d6 Compare December 1, 2020 15:36

finagolfin commented Dec 1, 2020

View reviewed changes

finagolfin mentioned this pull request Dec 2, 2020

[android] Switch armv7 vendor to 'unknown' in target triple to match other arches #34919

Merged

finagolfin force-pushed the core branch from ddd44d6 to 028571b Compare December 3, 2020 03:11

finagolfin mentioned this pull request Dec 14, 2020

Process: Adapt #2928 for Android swiftlang/swift-corelibs-foundation#2942

Merged

finagolfin force-pushed the core branch from 028571b to 443d5b4 Compare December 14, 2020 10:35

finagolfin force-pushed the core branch from 443d5b4 to c357a18 Compare February 1, 2021 17:36

finagolfin mentioned this pull request Feb 2, 2021

[android] Switch to new single-header modulemap for Bionic too #35707

Merged

finagolfin force-pushed the core branch from c357a18 to 58d89da Compare February 15, 2021 06:18

finagolfin mentioned this pull request Apr 14, 2021

[build] Allow cross-compiling build-script products for non-Darwin hosts too #36917

Merged

finagolfin force-pushed the core branch from 58d89da to db2d3e0 Compare April 14, 2021 21:44

finagolfin force-pushed the core branch from db2d3e0 to 6ebddd8 Compare May 26, 2021 19:10

gottesmm reviewed May 30, 2021

View reviewed changes

finagolfin force-pushed the core branch from b523e76 to a4ff4db Compare June 29, 2021 01:15

finagolfin mentioned this pull request Jun 29, 2021

[5.5][build] Add the flags to enable cross-compiling the corelibs #38146

Merged

varungandhi-apple merged commit a07b476 into swiftlang:main Jun 30, 2021

finagolfin mentioned this pull request Jun 30, 2021

[build] disable failing Android cross-compilation test on macOS #38181

Merged

finagolfin deleted the core branch June 30, 2021 21:25

finagolfin mentioned this pull request Jul 16, 2021

[build] Add a new flag to disable cross-compiling the compiler #38441

Open

[build] Add the flags to enable cross-compiling the corelibs #33724

[build] Add the flags to enable cross-compiling the corelibs #33724

Conversation

finagolfin commented Aug 31, 2020

gottesmm commented Sep 1, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

finagolfin commented Sep 2, 2020

finagolfin commented Dec 1, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

finagolfin commented Dec 3, 2020

finagolfin commented Dec 9, 2020

finagolfin commented May 27, 2021

gottesmm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gottesmm commented May 30, 2021

drexin commented Jun 26, 2021

swift-ci commented Jun 26, 2021

finagolfin commented Jun 26, 2021

drexin commented Jun 26, 2021

drexin commented Jun 26, 2021

swift-ci commented Jun 26, 2021

finagolfin commented Jun 26, 2021

finagolfin commented Jun 28, 2021

drexin commented Jun 28, 2021

swift-ci commented Jun 28, 2021

finagolfin commented Jun 28, 2021

gottesmm commented Jun 28, 2021

finagolfin commented Jun 29, 2021

swift-ci commented Jun 29, 2021

finagolfin commented Jun 29, 2021

drexin commented Jun 29, 2021

swift-ci commented Jun 29, 2021

finagolfin commented Jun 29, 2021

finagolfin commented Jun 29, 2021

drexin commented Jun 29, 2021

finagolfin commented Jun 30, 2021

shahmishal commented Jun 30, 2021

finagolfin commented Jun 30, 2021