Since Swift 6 >= every attempt of updating my preexistent Swift 5 from GURU fails due to this error. Reproducible: Always Steps to Reproduce: 1. Emerge dev-lang/swift-6.0.3
Created attachment 915412 [details] build.log
Created attachment 915413 [details] emerge -pqv output
Created attachment 915414 [details] emerge --info output
Hmm — it looks Swift is picking up the Clang C stdlib, which is picking up the Clang `_Builtin_intrinsics`, which is... picking up the GCC libstdc++? /var/tmp/portage/dev-lang/swift-6.0.3/work/swift/include/swift/Basic/BasicBridging.h:43:10: note: while building module 'std' imported from /var/tmp/portage/dev-lang/swift-6.0.3/work/swift/include/swift/Basic/BasicBridging.h:43: #include <cassert> ^ /usr/include/tbb/../oneapi/tbb/detail/_machine.h:44:10: note: while building module '_Builtin_intrinsics' imported from /usr/include/tbb/../oneapi/tbb/detail/_machine.h:44: #include <immintrin.h> // _mm_pause ^ <module-includes>:2:10: note: in file included from <module-includes>:2: #include "immintrin.h" ^ /usr/lib64/swift-5.10.1/usr/lib/swift/clang/include/immintrin.h:26:10: note: in file included from /usr/lib64/swift-5.10.1/usr/lib/swift/clang/include/immintrin.h:26: #include <xmmintrin.h> ^ /usr/lib64/swift-5.10.1/usr/lib/swift/clang/include/xmmintrin.h:31:10: note: in file included from /usr/lib64/swift-5.10.1/usr/lib/swift/clang/include/xmmintrin.h:31: #include <mm_malloc.h> ^ /usr/lib64/swift-5.10.1/usr/lib/swift/clang/include/mm_malloc.h:13:10: note: in file included from /usr/lib64/swift-5.10.1/usr/lib/swift/clang/include/mm_malloc.h:13: #include <stdlib.h> ^ /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/stdlib.h:36:11: error: cyclic dependency in module 'std': std -> _Builtin_intrinsics -> std # include <cstdlib> ^ I don't really know anything about this, but presumably, if `mm_malloc` was picking up the Clang stdlib, the right defines would be in place to break the cycle; but, it's also possible that the GCC libs here are a red herring. --- Nothing obvious stands out to me from `emerge --info`; all the flags look pretty standard, and match pretty much what I've got. The one thing that does stand out from `emerge -pqv` is that this appears to be an upgrade using `swift-5.10.1:0` (which predates `app-eselect/eselect-swift` and `dev-lang/swift-bootstrap`) and should be uninstalled in favor of the newer tooling.
Michał, if you're willing: instead of `emerge dev-lang/swift-6.0.3`, could you try `emerge -uUD --autounmask --autounmask-write dev-lang/swift` (with `etc-update` as needed) to see if removing the older, broken version of 5.10.1 leads to a working update?
I'm actually doing it right now. I removed =dev-lang/swift-5.10.1:0 and I'm installing dev-lang/swift-bootstrap and then I'll install dev-lang/swift:6
I've removed dev-lang/swift:0, installed dev-lang/swift-bootstrap with Swift 5.10.1-r2 and tried installing dev-lang/swift:6, it's failing in the same way
Swift build picking up /usr/include/oneapi/tbb/detail/_machine.h seems a bit suspicious. I made a *reverse dependency path* from dev-cpp/tbb on my system and it comes from media-libs/opencv. It does not seem like something Swift needs so I'd put my bet on this package as for what causes this issue.
Bummer, but thanks for confirming! I'll try to reproduce in a clean Docker image with OpenCV and see what I get. If you still have them in your history, would you mind sharing for reference the exact `emerge` commands you used to install `swift-bootstrap` and `swift`?
At the time you wrote #5 I already have unmerged dev-lang/swift:0 with --depclean, so it's not exactly what you told me to do. I did 1. emerge --deselect dev-lang/swift 2. emerge --depclean 3. emerge -a dev-lang/swift-bootstrap 4. emerge -a --autounmask --autounmask-write dev-lang/swift
No worries! That's helpful — I'd expect those steps to succeed even more than I would updating from the older `swift-5.10.1:0`. I'm currently running ebuildtester --gcc-version 13.3.1_p20241025 --portage-dir /var/db/repos/gentoo --overlay-dir /var/db/repos/guru --update --pull --unmask 'dev-lang/swift' --unmask 'dev-lang/swift-bootstrap' --unmask 'app-eselect/eselect-swift' --atom 'dev-lang/swift-6.0.3' to sanity-check that Swift is building as expected without OpenCV; I'll then test with OpenCV to see if that reproduces.
To pinpoint the issue even more so, dev-cpp/tbb is probably at fault. I found this, so that's an upstream bug: https://github.com/swiftlang/swift/issues/76166 My guess is that an install without dev-lang/tbb should work, then C++'s <execution> header should default to a different threading backend.
Can confirm the plain build succeeded, as expected. > To pinpoint the issue even more so, dev-cpp/tbb is probably at fault. Agreed! I'm trying again now with ebuildtester --gcc-version 13.3.1_p20241025 --portage-dir /var/db/repos/gentoo --overlay-dir /var/db/repos/guru --update --pull --unmask 'dev-lang/swift' --unmask 'dev-lang/swift-bootstrap' --unmask 'app-eselect/eselect-swift' --unmask 'dev-cpp/tbb' --atom 'dev-cpp/tbb-2022.0.0-r1' --atom 'dev-lang/swift-6.0.3' to confirm. > I found this, so that's an upstream bug: > https://github.com/swiftlang/swift/issues/76166 Good find! I hadn't gone hunting around for open issues yet, but this seems like a good place to start (and possibly to contribute some information to). --- One thing about `dev-cpp/tbb`: `equery d dev-cpp/tbb` shows me that, at least on my system, the only package that appears to depend on `dev-cpp/tbb` is `media-libs/opencv`: > $ equery d dev-cpp/tbb > * These packages depend on dev-cpp/tbb: > media-libs/opencv-4.10.0 (tbb ? dev-cpp/tbb[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]) > (tbb ? dev-cpp/tbb[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]) It looks like the `tbb` USE flag for it is off by default, though: > - - tbb : Enable multithreading with the Intel Threads Building Block (dev-cpp/tbb) I dug through the ebuild to see if this was enabled by default for Intel CPUs, but it doesn't appear to be. So theoretically, if you don't have a specific need to have TBB enabled for OpenCV, you could consider reinstalling with the `tbb` flag off to get unblocked in the meantime. (Though this is obviously not ideal!)
Unless someone wants to solve upstream problems, doing BDEPEND="!dev-cpp/tbb" in the Swift ebuild is somewhat of a temporary fix.
Okay, I can confirm that with `dev-cpp/tbb` installed, the build fails as encountered. I can `BDEPEND='!dev-cpp/tbb'`, but I'd like to do a little investigation first to see if there's a reasonable patch that can be submitted upstream (or added to the build) that would resolve this. In the meantime, Michał, if you'd be willing to temporarily remove `dev-cpp/tbb` in order to try to install Swift, please let me know if that succeeds.
I unfortunately have some other packages depending on `dev-cpp/tbb` at the moment and it'd be hard to remove them, but I think its safe to say that Swift and TBB conflict is to blame. I'm dabbling in fixing it upstream but for the time being I think it would be good to create a build dep conflict with `dev-cpp/tbb` so that other users won't waste 2 hours of build time just to crash.
Yeah, good call. I haven't had the time to investigate upstream further, so added as a (hopefully temporary) build blocker in https://gitweb.gentoo.org/repo/proj/guru.git/commit/?h=dev&id=5958bfb28afe8914b4b798f53ad10941b42220ca
Okay, I managed to fix this compilation error, the build is still ongoing but it looks fixable.
We'll have to cherrypick a fix from Swift 6 to Swift 5. This is a clusterfuck in Swift, but in the direct cause is the bootstrapping Swift 5. Swift 6 picks up host compiler headers (so, Swift 5), which are then including <execution>. I'll patch sometime in the future, but I have a pretty busy time right now so I can't spare more time to this issue right now.
Thanks for the investigation, Michał! I'm happy to pick up the work here. I don't know to what extent we can expect an upstream patch to go out for the Swift 5 compiler, but at the very least, a local patch should be doable. (It sounds from your description that it should be sufficient to backport https://github.com/swiftlang/swift/pull/75662 to swift-5.10.1 and then re-bootstrap Swift 6, which has the same patch, but I'll build to confirm.)
I think we can't expect upstream to proceed with further patching Swift 5, it doesn't look like they maintain two release branches. Yes, applying the mentioned pull request would fix stuff. I'd even go further and remove those ifdefs + include entirely. I haven't investigated but I have some doubts whether this fix worked with TBB at any point (I might be wrong, tho), we'd have to check a libstdc++-9 build if you want to bother with experimenting. I (for now) don't have an idea build testing setup, I test it on my PC which is pretty loud so if you want to take care of that, that'd be great. Also, I'd be good to push out some kind of eselect news for this change? I don't know whether this is doable for gentoo-guru, so you'd have to ask if you want.
> I think we can't expect upstream to proceed with further patching Swift 5, > it doesn't look like they maintain two release branches. The Swift 5.10.x compiler line will need to stick around (theoretically forever) to be able to bootstrap Swift 6+ on new (or source-only) platforms, so as far as I'm aware, the team is theoretically prepared to accept future patches — I'd open up a PR against `release/5.10` and talk to Mishal Shah about theoretically spinning up a 5.10.2 build... but I don't think this specific issue is so high priority that it would warrant a new build. I think keeping this as a Gentoo-local patch is sufficient. > Yes, applying the mentioned pull request would fix stuff. > I'd even go further and remove those ifdefs + include entirely. > I haven't investigated but I have some doubts whether this fix worked with > TBB at any point (I might be wrong, tho), we'd have to check a libstdc++-9 > build if you want to bother with experimenting. > > I (for now) don't have an idea build testing setup, I test it on my PC which > is pretty loud so if you want to take care of that, that'd be great. Can do! Building now, with the patch from #75662 applied directly, for the moment. Assuming the patch is correct, we need something like > BDEPEND+=" > || ( > !!<sys-devel/gcc-11 > !!dev-cpp/tbb > ) > " which is a little gnarly. I'm inclined to take your suggestion and exclude `<execution>` entirely. > Also, I'd be good to push out some kind of eselect news for this change? > I don't know whether this is doable for gentoo-guru, so you'd have to ask if > you want. Good question — based on https://devmanual.gentoo.org/general-concepts/news/index.html and what I've seen of `eselect news` documentation, this is only possible for the mainline Gentoo repo (and high-profile, important announcements), but it's possible I've missed something. To the best of my knowledge, news items are fetched in `/var/db/repos/gentoo/metadata/news`, and `/var/db/repos/guru/metadata` doesn't have a news dir, so I'm inclined to believe this isn't done.
Can confirm that by applying the patch to Swift 5.10.1, I'm able to bootstrap Swift 6 with `dev-cpp/tbb` installed. I'd like to test the patch with <libstdc++-11 to see if taking the patch as-is is reasonable, or whether we have to exclude `<execution>` altogether.
Ah, maybe we don't care? Gentoo doesn't support GCC <11: > /var/db/repos/gentoo/profiles/package.mask: > # Sam James <sam@gentoo.org> (2024-09-30) > # GCC 10 and older no longer receive upstream support or fixes for > # bugs. Please switch to a newer GCC version using gcc-config. > # The lowest supported version of GCC is GCC 11. I'm going to test anyway, just to be sure.
It turns out that it's a pain to try to get a system with only GCC <11 installed, if possible at all these days (the Gentoo 23.0 profile explicitly requires GCC >=11, but even with 17.1, it seems the system forces the latest GCC anyway). I'm comfortable adding `BDEPEND=">=sys-devel/gcc-11"` to both Swift 5 and 6 to be safe, and backporting the patch to Swift 5 locally.
I've pushed out * https://gitweb.gentoo.org/repo/proj/guru.git/commit/?h=dev&id=713f3eb13fb675ca4260a859aea01b2202de0f23 * https://gitweb.gentoo.org/repo/proj/guru.git/commit/?h=dev&id=1e8cb85c79c4feabd23e999cda27c1cfbdb90cc9
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=1e8cb85c79c4feabd23e999cda27c1cfbdb90cc9 commit 1e8cb85c79c4feabd23e999cda27c1cfbdb90cc9 Author: Itai Ferber <itai@itaiferber.net> AuthorDate: 2025-01-15 19:50:17 +0000 Commit: Itai Ferber <itai@itaiferber.net> CommitDate: 2025-01-15 19:53:29 +0000 dev-lang/swift: remove dev-cpp/tbb as a strong blocker for Swift 6 Swift 6 builds with `dev-cpp/tbb` installed on systems with >=libstdc++-11 (the minimum version currently supported by Gentoo) as long as it's bootstrapped by swift-5.10.1-r3 or later (which has a patch backported from Swift 6 which prevents `<execution>` from getting picked up). Bug: https://bugs.gentoo.org/947141 Signed-off-by: Itai Ferber <itai@itaiferber.net> dev-lang/swift/swift-6.0.1-r1.ebuild | 13 +------------ dev-lang/swift/swift-6.0.1.ebuild | 13 +------------ dev-lang/swift/swift-6.0.2.ebuild | 13 +------------ dev-lang/swift/swift-6.0.3.ebuild | 13 +------------ 4 files changed, 4 insertions(+), 48 deletions(-) https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=713f3eb13fb675ca4260a859aea01b2202de0f23 commit 713f3eb13fb675ca4260a859aea01b2202de0f23 Author: Itai Ferber <itai@itaiferber.net> AuthorDate: 2025-01-15 19:48:54 +0000 Commit: Itai Ferber <itai@itaiferber.net> CommitDate: 2025-01-15 19:53:29 +0000 dev-lang/swift: add 5.10.1-r3 Backports Swift #75662 to enable building with `dev-cpp/tbb` Bug: https://bugs.gentoo.org/947141 Signed-off-by: Itai Ferber <itai@itaiferber.net> .../swift-5.10.1-r3/backport-swift-75662.patch | 21 ++ .../swift-5.10.1-r3/backtracing-noexecstack.patch | 1 + .../disable-libdispatch-werror.patch | 1 + .../files/swift-5.10.1-r3/link-ncurses-tinfo.patch | 1 + .../files/swift-5.10.1-r3/link-with-lld.patch | 1 + .../lldb-cmake-minimum-version.patch | 1 + dev-lang/swift/swift-5.10.1-r3.ebuild | 341 +++++++++++++++++++++ 7 files changed, 367 insertions(+)
Michał, if you get the chance, let me know if patches resolved the issue for you if you re-bootstrap — happy to iterate if needed!
