So the problem here is actually that something has gone horribly wrong when configuring compiler- rt.
You'll notice in the clang commands that it is building in this directory:
clang_rt.builtins_armv7_10.4.dir
What that means is it is building the clang_rt.10.4 archive which provides back ported library functions to OS X 10.4. Obviously 10.4 didn't support armv7 as an architecture, something has gone really wrong here.
If you're on the latest swift it is probably a regression caused by 53f48f8. You need to email swift-dev to get support from Dmitri Gribenko and Vedant Kumar.
Source: I wrote most of the compiler-rt builtin build system for Darwin.
Andrew Hyatt
ahyattdev@icloud.com
···
On Mar 19, 2016, at 9:26 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
Building swift-llvm fails when using build-script to cross compile because build-script wrongly gives duplicate -isysroot arguments.
This error occurs after the phase of building llvm for the host machine, and occurs during the cross compilation phase.
Andrew Hyatt
andythehyatt@gmail.com <mailto:andythehyatt@gmail.com>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
I'm not super familiar with the swift build scripts, but I have a theory of what is going wrong. I think the problem is that compiler-rt is being built during the cross build, and it really shouldn't be.
The compiler-rt build system has some significant flaws, and it is being reworked to resolve them. The problem causing this is that we have a hacked up CMake build process that generates multiple cross-targeted binaries from a single build configuration. I believe that compiler-rt's built-in hacky cross-targeting is tripping over however swift is supporting cross-targeting, and it is falling over.
With the current state of compiler-rt the right way to build it for Darwin is to treat it as host content, and it will build the Darwin-cross libraries too. Then you can pull the cross-libraries out and put them into the device build.
Vedant, if you have questions feel free to swing by my office on Monday.
-Chris
···
On Mar 19, 2016, at 10:11 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
(From /u/thegreatbeanz on reddit.com/r/swift)
So the problem here is actually that something has gone horribly wrong when configuring compiler- rt.
You'll notice in the clang commands that it is building in this directory:
clang_rt.builtins_armv7_10.4.dir
What that means is it is building the clang_rt.10.4 archive which provides back ported library functions to OS X 10.4. Obviously 10.4 didn't support armv7 as an architecture, something has gone really wrong here.
If you're on the latest swift it is probably a regression caused by 53f48f8. You need to email swift-dev to get support from Dmitri Gribenko and Vedant Kumar.
Source: I wrote most of the compiler-rt builtin build system for Darwin.
Andrew Hyatt
ahyattdev@icloud.com
On Mar 19, 2016, at 9:26 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
Building swift-llvm fails when using build-script to cross compile because build-script wrongly gives duplicate -isysroot arguments.
I'm not super familiar with the swift build scripts, but I have a theory of what is going wrong. I think the problem is that compiler-rt is being built during the cross build, and it really shouldn't be.
The compiler-rt build system has some significant flaws, and it is being reworked to resolve them. The problem causing this is that we have a hacked up CMake build process that generates multiple cross-targeted binaries from a single build configuration. I believe that compiler-rt's built-in hacky cross-targeting is tripping over however swift is supporting cross-targeting, and it is falling over.
With the current state of compiler-rt the right way to build it for Darwin is to treat it as host content, and it will build the Darwin-cross libraries too. Then you can pull the cross-libraries out and put them into the device build.
Could you elaborate on what it means to treat it as host content?
Is setting COMPILER_RT_HOST_TRIPLE and disabling COMPILER_RT_ENABLE_{I,TV,WATCH}OS the right thing to do?
Vedant, if you have questions feel free to swing by my office on Monday.
Will do.
thanks,
vedant
···
On Mar 19, 2016, at 12:05 PM, ChrisBieneman <beanz@apple.com> wrote:
-Chris
On Mar 19, 2016, at 10:11 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
(From /u/thegreatbeanz on reddit.com/r/swift)
So the problem here is actually that something has gone horribly wrong when configuring compiler- rt.
You'll notice in the clang commands that it is building in this directory:
clang_rt.builtins_armv7_10.4.dir
What that means is it is building the clang_rt.10.4 archive which provides back ported library functions to OS X 10.4. Obviously 10.4 didn't support armv7 as an architecture, something has gone really wrong here.
If you're on the latest swift it is probably a regression caused by 53f48f8. You need to email swift-dev to get support from Dmitri Gribenko and Vedant Kumar.
Source: I wrote most of the compiler-rt builtin build system for Darwin.
Andrew Hyatt
ahyattdev@icloud.com
On Mar 19, 2016, at 9:26 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
Building swift-llvm fails when using build-script to cross compile because build-script wrongly gives duplicate -isysroot arguments.
I'm not super familiar with the swift build scripts, but I have a theory of what is going wrong. I think the problem is that compiler-rt is being built during the cross build, and it really shouldn't be.
The compiler-rt build system has some significant flaws, and it is being reworked to resolve them. The problem causing this is that we have a hacked up CMake build process that generates multiple cross-targeted binaries from a single build configuration. I believe that compiler-rt's built-in hacky cross-targeting is tripping over however swift is supporting cross-targeting, and it is falling over.
With the current state of compiler-rt the right way to build it for Darwin is to treat it as host content, and it will build the Darwin-cross libraries too. Then you can pull the cross-libraries out and put them into the device build.
Could you elaborate on what it means to treat it as host content?
I don't know the exact details of how swift's build scripts work, but I assume it isn't that different from how you generally would cross-compile a compiler and runtimes.
For example, if I wanted to build clang for iOS, the first thing I would do is build a host-capable clang that could target iOS. That clang is then be used to build the cross-targeted clang and corresponding runtimes. I assume swift does something similar to solve version incompatibilities between the host compiler and the target.
Compiler-RT's build system is really screwy for a lot of reasons. On Darwin when you configure compiler-rt it tries to generate a single build tree that can target every Darwin-based platform. The logic around that gets really tripped up if you start trying to treat it as a cross-compile (even though it really is). This is something I'm working to fix.
The correct way to build compiler-rt on Darwin is to build it in-tree as part of the host LLVM. If you're building a full host clang you can use the LLVM_BUILD_EXTERNAL_COMPILER_RT option to enable using the just-built clang. You can set COMPILER_RT_ENABLE_{platform} and it should be fine.
When you build the cross-targeted tools and libraries, you'll want to disable building compiler-rt by setting LLVM_TOOL_COMPILER_RT_BUILD=Off. After the cross-build completes you'll need to pull the clang_rt libraries out of the host build directory into the target compiler's build directory.
Hopefully I'll have this all re-worked in LLVM sometime in the next couple months, then it will all change all over again :-).
-Chris
···
On Mar 19, 2016, at 4:30 PM, Vedant Kumar <vsk@apple.com> wrote:
On Mar 19, 2016, at 12:05 PM, ChrisBieneman <beanz@apple.com> wrote:
Is setting COMPILER_RT_HOST_TRIPLE and disabling COMPILER_RT_ENABLE_{I,TV,WATCH}OS the right thing to do?
Vedant, if you have questions feel free to swing by my office on Monday.
Will do.
thanks,
vedant
-Chris
On Mar 19, 2016, at 10:11 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
(From /u/thegreatbeanz on reddit.com/r/swift)
So the problem here is actually that something has gone horribly wrong when configuring compiler- rt.
You'll notice in the clang commands that it is building in this directory:
clang_rt.builtins_armv7_10.4.dir
What that means is it is building the clang_rt.10.4 archive which provides back ported library functions to OS X 10.4. Obviously 10.4 didn't support armv7 as an architecture, something has gone really wrong here.
If you're on the latest swift it is probably a regression caused by 53f48f8. You need to email swift-dev to get support from Dmitri Gribenko and Vedant Kumar.
Source: I wrote most of the compiler-rt builtin build system for Darwin.
Andrew Hyatt
ahyattdev@icloud.com
On Mar 19, 2016, at 9:26 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
Building swift-llvm fails when using build-script to cross compile because build-script wrongly gives duplicate -isysroot arguments.
5e342aa fixed the CFLAGS issue for swift-llvm and it now compiles fine for iOS.
A remnant of the issue persists while building Swift. To get to that point I copied over two headers not present in the iOS SDK (crt_externs.h and histedit.h).
Andrew, which compiler invocations prompted you to copy these files over?
While building swift, I get the following error:
clang: error: invalid argument '-mmacosx-version-min=10.11' not allowed with '-miphoneos-version-min=7.0’
The arguments clang++ was launched with when the error occurred:
It looks like some of the logic in SourceKit's build scripts is tripping up.
Argyrios has done a lot of work on SourceKit, maybe he'll be able to spot the issue.
vedant
···
On Mar 21, 2016, at 8:06 PM, Andrew Hyatt <ahyattdev@icloud.com> wrote:
Compiling LLVM works now, so maybe just one more change is needed to fix this build system issue for swift.
Thanks you, Apple!
Also, great job on the 2.2 release and good luck with 3.0.
Andrew Hyatt
ahyattdev@icloud.com
On Mar 19, 2016, at 4:30 PM, Vedant Kumar <vsk@apple.com> wrote:
On Mar 19, 2016, at 12:05 PM, ChrisBieneman <beanz@apple.com> wrote:
[Adding Vedant directly]
I'm not super familiar with the swift build scripts, but I have a theory of what is going wrong. I think the problem is that compiler-rt is being built during the cross build, and it really shouldn't be.
The compiler-rt build system has some significant flaws, and it is being reworked to resolve them. The problem causing this is that we have a hacked up CMake build process that generates multiple cross-targeted binaries from a single build configuration. I believe that compiler-rt's built-in hacky cross-targeting is tripping over however swift is supporting cross-targeting, and it is falling over.
With the current state of compiler-rt the right way to build it for Darwin is to treat it as host content, and it will build the Darwin-cross libraries too. Then you can pull the cross-libraries out and put them into the device build.
Could you elaborate on what it means to treat it as host content?
Is setting COMPILER_RT_HOST_TRIPLE and disabling COMPILER_RT_ENABLE_{I,TV,WATCH}OS the right thing to do?
Vedant, if you have questions feel free to swing by my office on Monday.
Will do.
thanks,
vedant
-Chris
On Mar 19, 2016, at 10:11 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
(From /u/thegreatbeanz on reddit.com/r/swift)
So the problem here is actually that something has gone horribly wrong when configuring compiler- rt.
You'll notice in the clang commands that it is building in this directory:
clang_rt.builtins_armv7_10.4.dir
What that means is it is building the clang_rt.10.4 archive which provides back ported library functions to OS X 10.4. Obviously 10.4 didn't support armv7 as an architecture, something has gone really wrong here.
If you're on the latest swift it is probably a regression caused by 53f48f8. You need to email swift-dev to get support from Dmitri Gribenko and Vedant Kumar.
Source: I wrote most of the compiler-rt builtin build system for Darwin.
Andrew Hyatt
ahyattdev@icloud.com
On Mar 19, 2016, at 9:26 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
Building swift-llvm fails when using build-script to cross compile because build-script wrongly gives duplicate -isysroot arguments.
5e342aa fixed the CFLAGS issue for swift-llvm and it now compiles fine for iOS.
A remnant of the issue persists while building Swift. To get to that point I copied over two headers not present in the iOS SDK (crt_externs.h and histedit.h).
Andrew, which compiler invocations prompted you to copy these files over?
While building swift, I get the following error:
clang: error: invalid argument '-mmacosx-version-min=10.11' not allowed with '-miphoneos-version-min=7.0’
The arguments clang++ was launched with when the error occurred:
It looks like some of the logic in SourceKit's build scripts is tripping up.
Argyrios has done a lot of work on SourceKit, maybe he'll be able to spot the issue.
I don’t think SourceKit cpp files do anything special with CMake, are you sure this only shows up for SourceKit files, is everything else building fine ?
You could workaround by disabling building it with CMake variable, SWIFT_BUILD_SOURCEKIT=FALSE
···
On Mar 22, 2016, at 9:52 AM, Vedant Kumar <vsk@apple.com> wrote:
On Mar 21, 2016, at 8:06 PM, Andrew Hyatt <ahyattdev@icloud.com> wrote:
vedant
Compiling LLVM works now, so maybe just one more change is needed to fix this build system issue for swift.
Thanks you, Apple!
Also, great job on the 2.2 release and good luck with 3.0.
Andrew Hyatt
ahyattdev@icloud.com
On Mar 19, 2016, at 4:30 PM, Vedant Kumar <vsk@apple.com> wrote:
On Mar 19, 2016, at 12:05 PM, ChrisBieneman <beanz@apple.com> wrote:
[Adding Vedant directly]
I'm not super familiar with the swift build scripts, but I have a theory of what is going wrong. I think the problem is that compiler-rt is being built during the cross build, and it really shouldn't be.
The compiler-rt build system has some significant flaws, and it is being reworked to resolve them. The problem causing this is that we have a hacked up CMake build process that generates multiple cross-targeted binaries from a single build configuration. I believe that compiler-rt's built-in hacky cross-targeting is tripping over however swift is supporting cross-targeting, and it is falling over.
With the current state of compiler-rt the right way to build it for Darwin is to treat it as host content, and it will build the Darwin-cross libraries too. Then you can pull the cross-libraries out and put them into the device build.
Could you elaborate on what it means to treat it as host content?
Is setting COMPILER_RT_HOST_TRIPLE and disabling COMPILER_RT_ENABLE_{I,TV,WATCH}OS the right thing to do?
Vedant, if you have questions feel free to swing by my office on Monday.
Will do.
thanks,
vedant
-Chris
On Mar 19, 2016, at 10:11 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
(From /u/thegreatbeanz on reddit.com/r/swift)
So the problem here is actually that something has gone horribly wrong when configuring compiler- rt.
You'll notice in the clang commands that it is building in this directory:
clang_rt.builtins_armv7_10.4.dir
What that means is it is building the clang_rt.10.4 archive which provides back ported library functions to OS X 10.4. Obviously 10.4 didn't support armv7 as an architecture, something has gone really wrong here.
If you're on the latest swift it is probably a regression caused by 53f48f8. You need to email swift-dev to get support from Dmitri Gribenko and Vedant Kumar.
Source: I wrote most of the compiler-rt builtin build system for Darwin.
Andrew Hyatt
ahyattdev@icloud.com
On Mar 19, 2016, at 9:26 AM, Andrew Hyatt via swift-dev <swift-dev@swift.org> wrote:
Building swift-llvm fails when using build-script to cross compile because build-script wrongly gives duplicate -isysroot arguments.