-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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
[CMake 3.25+]: Swift 5.8: Fails to compile bootstrap1 modules #65028
Comments
I see similar issues on Ubuntu 20.04, but can you first make sure that all package dependencies are installed? I know you listed it in your steps, but if you missed something, it may cause this. |
@buttaface Thanks for the assistance, I've verified all of that and have attempted much more. It's my understanding that the C++ standard library Ubuntu ships with does not include a modulemap. Instead, the swift team includes it at the path: I've also attempted modifications to the modulemap in an attempt to resolve this. I also made changes to the The logs to me look look like the |
Having dealt with these modulemap issues for years, my guess is that the organization of the C++ stdlib headers changed with 23.04 and the current ordering for 20.04/22.04 doesn't work with the latest Ubuntu, as the Of course, that doesn't explain why I see similar errors on 20.04 too, so maybe there's some implicit dependency we're missing. |
@futurejones, I see you just released builds for Ubuntu 23.04, any idea how to fix these build issues we're seeing on Ubuntu? |
@buttaface I had 2 issues when first trying to build swift on ubuntu 23.04
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
<unknown>:0: error: unable to execute command: Illegal instruction
<unknown>:0: error: compile command failed due to signal 4 (use -v to see invocation)
[1223/1463][ 83%][2189.922s] Compiling /home/build-user/build/buildbot_linux/swift-linux-x86_64/bootstrapping0/stdlib/public/core/LINUX/x86_64/Swift.o
FAILED: bootstrapping0/stdlib/public/core/LINUX/x86_64/Swift.o
I am building with the following comand without any problems - |
Thanks @futurejones, maybe that's it, @jaredjones, as I'm building with one of the latest CMake releases, 3.26.1. I will try downgrading to what the linux CI is using and see if that makes a difference, you should try that too. |
Yep, that's it, the problem goes away after downgrading to CMake 3.19.6. I'll look into what flags recent CMake is adding that causes these build issues. |
I can also confirm that downgrading |
Checked the failing command, it is identical between the two CMake versions. This implies some other build input is being generated differently based on the CMake version, will dig deeper. |
Narrowed it down further: built LLVM with CMake 3.26.1 and then built the Swift compiler first with CMake 3.26.1, then wiped it and built with 3.19.6 and now could reproduce the problem with both, so it looks like the issue is in some LLVM file generated by CMake. I think this may be what caused my similar problems on Android in #60272 too, will look into it more. |
For what it's worth, I'm also seeing this exact error packaging Swift 5.8 in NixOS. CMake 3.24.3 works, while 3.25.3 doesn't. (I'm not sure if it was already established this was a CMake >=3.25 issue. I wanted to narrow the range.) I tried to diff the result of the configure step for LLVM between the two CMake versions, but nothing really stands out. (But I'm no expert.) |
Thanks, @stephank, I suspect some modulemap is generated differently between the two CMake versions, but I've had to put investigating this CMake issue further on the back burner while dealing with more important things. I tried downgrading the CMake used for my Android build, but it made no difference there, so that is a different C++ Interop error. @compnerd or @stevapple, have you guys seen this issue with recent CMake on Windows too? |
It looks like the modulemap is completely missing, and
|
Found a little time, and:
But I'm unable to reproduce this in a small test setup, so something is fishy. Seems like it should be something specific to these checks, or it'd be far more widespread. |
After sleeping on it, I realized this is simply because As it turns out, CMake defines So the current way we write these expressions is a little ambiguous. Quoting seems to help, and ensures CMake treats it as a string. I do believe we have more broken checks like this; will create a PR. |
@jaredjones, would you reopen this and add the CMake version info to the title? Once @stephank submits a fix, he can close it. |
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`, etc. These conflict with expressions that used these names as unquoted strings in positions where CMake accepts 'variable|string', for example: - `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and expands to 1, where it would previously coerce to a string. - `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the left-hand side expands twice. In this patch, I looked for a number of patterns to fix up, sometimes a little defensively: - Quoted right-hand side of `STREQUAL` where I was confident it was intended to be a string literal. - Removed manual variable expansion on left-hand side of `STREQUAL`, `MATCHES` and `IN_LIST` where I was confident it was unintended. Fixes swiftlang#65028.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`, etc. These conflict with expressions that used these names as unquoted strings in positions where CMake accepts 'variable|string', for example: - `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and expands to 1, where it would previously coerce to a string. - `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the left-hand side expands twice. In this patch, I looked for a number of patterns to fix up, sometimes a little defensively: - Quoted right-hand side of `STREQUAL` where I was confident it was intended to be a string literal. - Removed manual variable expansion on left-hand side of `STREQUAL`, `MATCHES` and `IN_LIST` where I was confident it was unintended. Fixes swiftlang#65028.
See #65534 |
I'm also experienceing this problem when I tried to make a Swift 5.8 build for Arch Linux aarch64. (I'm using "GNU Make 3.81")
|
this is unrelated to the erro am seeing on arch: which tachoknight worked around by a patch to build swift for fedora? https://github.com/tachoknight/swift-lang-packaging-fedora/tree/5.8 |
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`, etc. These conflict with expressions that used these names as unquoted strings in positions where CMake accepts 'variable|string', for example: - `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and expands to 1, where it would previously coerce to a string. - `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the left-hand side expands twice. In this patch, I looked for a number of patterns to fix up, sometimes a little defensively: - Quoted right-hand side of `STREQUAL` where I was confident it was intended to be a string literal. - Removed manual variable expansion on left-hand side of `STREQUAL`, `MATCHES` and `IN_LIST` where I was confident it was unintended. Fixes swiftlang#65028.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`, etc. These conflict with expressions that used these names as unquoted strings in positions where CMake accepts 'variable|string', for example: - `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and expands to 1, where it would previously coerce to a string. - `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the left-hand side expands twice. In this patch, I looked for a number of patterns to fix up, sometimes a little defensively: - Quoted right-hand side of `STREQUAL` where I was confident it was intended to be a string literal. - Removed manual variable expansion on left-hand side of `STREQUAL`, `MATCHES` and `IN_LIST` where I was confident it was unintended. Fixes swiftlang#65028.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`, etc. These conflict with expressions that used these names as unquoted strings in positions where CMake accepts 'variable|string', for example: - `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and expands to 1, where it would previously coerce to a string. - `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the left-hand side expands twice. In this patch, I looked for a number of patterns to fix up, sometimes a little defensively: - Quoted right-hand side of `STREQUAL` where I was confident it was intended to be a string literal. - Removed manual variable expansion on left-hand side of `STREQUAL`, `MATCHES` and `IN_LIST` where I was confident it was unintended. Fixes swiftlang#65028.
@compnerd FYI I also ran into this issue while building Swift on Exherbo using I can see there's an open PR for Swift 5.9, I'll try building the main branch then (which has been applied a fix). Edit: I have CMake 3.25.1 installed by the way |
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`, etc. These conflict with expressions that used these names as unquoted strings in positions where CMake accepts 'variable|string', for example: - `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and expands to 1, where it would previously coerce to a string. - `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the left-hand side expands twice. In this patch, I looked for a number of patterns to fix up, sometimes a little defensively: - Quoted right-hand side of `STREQUAL` where I was confident it was intended to be a string literal. - Removed manual variable expansion on left-hand side of `STREQUAL`, `MATCHES` and `IN_LIST` where I was confident it was unintended. Fixes swiftlang#65028.
Description
Ubuntu 23.04 + Swift 5.8: Fails to compile bootstrap1 modules due to possible module map issues with CXX interop
When compiling Swift from source with
--bootstrapping=bootstrapping
, compilation fails during generation of modules. Specifically on the Basic module.Steps to reproduce
./swift/utils/update-checkout --clone --tag swift-5.8-RELEASE
build-script
as follows:Expected behavior
Bootstrap compilation should succeed, however a failure occurs when
swiftc
is invoked and has to deal withcxx-interop
.Build Failure
Environment
The full build-log is attached.
swift_build_failure.txt
The text was updated successfully, but these errors were encountered: