-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Linux packages fail to build with LLVM 18 and Apple 2023 versions of clang #7241
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
Linux packages fail to build with LLVM 18 and Apple 2023 versions of clang #7241
Conversation
Sources/Build/BuildDescription/ClangTargetBuildDescription.swift
Outdated
Show resolved
Hide resolved
There's some chance here that is would break older packages which rely on the existing behavior, but it doesn't seem that likely that there's code that requires modules in C-based targets. Unfortunately, the compatibility suite is only for macOS AFAIK (cc @shahmishal). Do we need any way for package authors to opt-in to modules? They can do so via unsafe flags, but that comes with restrictions on the use of their packages. |
We do support Linux source compat suite - |
Thanks, Mishal, I didn't know that! We should test this PR with those jobs to see if there's impact. |
Awesome, @shahmishal how do I invoke those suites with this change? Or do I just need to land it and someone will yell at me if they break? |
…clang Newer versions of clang add builtin modules for its C Standard Library headers. This creates problems* when building with a single module map that tries to absorb all of the OS/SDK dependencies, which is what all non-Apple platforms currently do in SPM. This works for Swift targets because the Swift compiler injects module maps via vfs for non-Apple platforms. However, clang doesn't do anything similar for C-based targets, and so they fail to build. For now, don't build with modules for any SPM C-based targets on non-Apple platforms. * Some problems are module cycles and headers being absorbed into unexpected modules. clang modules generally expect that OS/SDK headers are covered by module maps, and _not_ absorbed into whatever module happens to include them first. rdar://120716498
@swift-ci smoke test |
@swift-ci test |
Newer versions of clang add builtin modules for its C Standard Library headers. This creates problems* when building with a single module map that tries to absorb all of the OS/SDK dependencies, which is what all non-Apple platforms currently do in SwiftPM.
This works for Swift targets because the Swift compiler injects module maps via vfs for non-Apple platforms. However, clang doesn't do anything similar for C-based targets, and so they fail to build.
For now, don't build with modules for any SwiftPM C-based targets on non-Apple platforms.
* Some problems are module cycles and headers being absorbed into unexpected modules. clang modules generally expect that OS/SDK headers are covered by module maps, and not absorbed into whatever module happens to include them first.
rdar://120716498