=kde-frameworks/syntax-highlighting-5.97.0 fails to build Reproducible: Always Steps to Reproduce: 1. Attempt to build =kde-frameworks/syntax-highlighting-5.97.0 2. Wait. Actual Results: Build fails Expected Results: Build succeeds. Attached build.log and emerge --info
Created attachment 799829 [details] build.log
Created attachment 799831 [details] emerge --info
Please test with 5.98.0.
I've been away for awhile. Problem still persists with =kde-frameworks/syntax-highlighting-5.101.0 Attaching new build.log
Created attachment 842949 [details] new build.log (Dec 16 2022)
Created attachment 842951 [details] new emerge --info (Dec 16 2022)
Same exact issue here. Same build.log. Should we be reporting this upstream or is this a musl issue?
I'm using Clang+LLD, no musl here.
I tried with Clang and GCC, no LTO etc etc, problem persists and i am unable to upgrade my system because of it
*** Bug 890604 has been marked as a duplicate of this bug. ***
It'd help if could narrow down a bit which component being built with Clang breaks this - it sounds like it happens if something in addition to syntax-highlighting is built with Clang.
My complete guess is qtdeclarative or qtxmlpatterns being miscompiled by Clang. DEPEND=" >=dev-qt/qtdeclarative-${QTMIN}:5 >=dev-qt/qtgui-${QTMIN}:5 >=dev-qt/qtnetwork-${QTMIN}:5 >=dev-qt/qtxmlpatterns-${QTMIN}:5 " RDEPEND="${DEPEND}" BDEPEND=" dev-lang/perl >=dev-qt/linguist-tools-${QTMIN}:5 " Please recompile all of these with GCC then tell me if the problem continues. Then we can narrow it down and go from there. I can't reproduce when I just build syntax-highlighting with Clang (it works).
I was redirected here with the instruction to build the aforementioned packages with GCC, but to no avail, dev-qt/qtdeclarative-5.15.8-r2 and dev-qt/qtxmlpatterns-5.15.8 both fail to build because of g++ complaining about "g++: error: unrecognized command-line option ‘-Winconsistent-missing-override’". Do I need to post build logs and other info?
(In reply to tigrmango from comment #13) > I was redirected here with the instruction to build the aforementioned > packages with GCC, but to no avail, dev-qt/qtdeclarative-5.15.8-r2 and > dev-qt/qtxmlpatterns-5.15.8 both fail to build because of g++ complaining > about "g++: error: unrecognized command-line option > ‘-Winconsistent-missing-override’". Do I need to post build logs and other > info? Ah, you may need to do qtcore first.
recompiled all of the aforementioned packages with GCC and problem was solved, thank you
(In reply to tigrmango from comment #15) > recompiled all of the aforementioned packages with GCC and problem was > solved, thank you Thanks, that narrows it down! So, it's one of (or multiple of): - dev-qt/qtcore:5 (decent chance) - dev-qt/qtdeclarative:5 (decent chance) - dev-qt/qtgui:5 - dev-qt/qtnetwork:5 - dev-qt/qtxmlpatterns:5 (decent chance) - dev-qt/linguist-tools:5 (decent chance) - dev-lang/perl (super unlikely) If someone could try figure out precisely the minimal packages from the above list that require building with Clang to cause syntax-highlighting to break, that would be most helpful.
My recompiled with GCC packages were: dev-qt/qtcore-5.15.8, dev-qt/qtdeclarative-5.15.8-r2, dev-qt/qtxmlpatterns-5.15.8 and kde-frameworks/syntax-highlighting-5.101.0. After this and a reboot system was again working perfectly
I'm a bit OCD when it comes to Gentoo and toolchain bootstrapping.. I've ran emerge -eNDv @world a few times after recompiling llvm, clang, lld, clang-runtime clang-common llvm-libunwind libomp libcxx libcxxabi compiler-rt compiler-rt-sanitizers etc etc against themselves several times. I wouldn't open a bug otherwise.
Sam, misread your post. "minimal packages from the above list that require building with Clang to cause syntax-highlighting to break" I see now. Yes, this is a good idea, thanks! Alec
(In reply to Christoph Cullmann from https://bugs.kde.org/show_bug.cgi?id=462084#c1) > This looks like a broken index executable
I've only rebuilt qtxmlpatterns and qtcore with gcc. After that syntax-highlighting builds even with clang against qt built with gcc. (I've built it with ebuild tool to not touch other dependencies) The reason I had to rebuild qtcore is because it seems that qtxmlpatterns somehow inherits clang build flags from qtcore that gcc does not support. So qtxmlpatterns does not build with gcc on its own. After successfully building syntax-highlighting I've switched qt libs back to clang.
I'm facing the same kde-frameworks/syntax-highlighting and the kbuildsycoca5 issues with LLVM toolchain version 15.0.6 and 15.0.7. After looking with qlop the last working build of Qt should've been with clang 15.0.5 and after downgrading clang 15.0.5 does build a working Qt.
(In reply to Jonas Rakebrandt from comment #22) > I'm facing the same kde-frameworks/syntax-highlighting and the kbuildsycoca5 > issues with LLVM toolchain version 15.0.6 and 15.0.7. After looking with > qlop the last working build of Qt should've been with clang 15.0.5 and after > downgrading clang 15.0.5 does build a working Qt. Could you restore clang-15.0.x.9999 from git history and try bisect?
After some more investigation I don't think it's related to the clang version (there only were 3 commits from 15.0.5 to 15.0.6; none looking like they affect this). I had some success downgrading sys-devel/clang-common to 15.0.6 (the one before the hardening got introduced) and now Qt seems to build fine on one of my systems. However when I tried the same exact settings on another system the issue didn't get fixed. All in all this seems really random and hard to track down...
Did some more testing and Qt builds consistently with the latest LLVM toolchain if you use very barebones C{,XX}FLAGS (-march=native -O2 -pipe) and remove the @gentoo-hardened.cfg entry from /etc/clang/gentoo-common.cfg. However this feels more like a dirty workaround than a proper solution. It would still be nice if someone else could test this to see if this also works for them.
Running into the same issue, and for me it seems to be sufficient to rebuild qtcore with -O2 instead of -O3 to solve the compilation issue with syntax-highlighting. I didn't change anything in Gentoo's clang configuration, nor did I switch packages to GCC. I don't use overly aggressive CXXFLAGS: -O3 -march=native -mtune=native -pipe -fomit-frame-pointer ... and no hardening flags. Note that I updated my system to new Qt etc. some time last week, and when I rebooted earlier today, my Plasma desktop was sort of broken - in particular, krunner does not find any applications, and Yakuake does not find its konsole part, also the icon theme is no longer being applied. I was hoping that another world upgrade, now updating kde-frameworks too, would fix the issues, which is when I ran into the compilation error. I'll continue the world upgrade now with (only) qtcore built with -O2, and see if my system works properly afterwards - if some of the Qt indexing tools are miscompiled, it seems that could well be the cause for issues with Plasma's indexes of applications and other things...
Yes, that would be partly covered by the second upstream bug linked @See Also.
Indeed, rerunning kbuildsycoca5 after rebuilding qtcore with -O2 brings my system back to life again. Haven't done a full logout/login cycle yet, but icons and applications are back, so I assume the rest will be fixed as well. Also Yakuake works again.
... and now I ran into this issue on a different system with almost exactly the same configuration, and rebuilding qtcore and other Qt modules with any combination of flags I tried does not solve it. I'm at a loss...
Okay, maybe I'm getting closer to solving the mystery: I was fiddling around with CXXFLAGS. Since simply changing to -O2 didn't help on this machine, I tried to remove one of the other flags (-march=native), rebuilt qtcore, and voila, compilation of syntax-highlighting succeeded. Readd flag, compilation fails again. Change -O2 to -O3, compilation fails. Add "-O3 -O3", compilation succeeds. And then, since it really doesn't make sense that a miscompilatio would be so sensitive to order of things in the command line, I got the glorious idea to rebuild qtcore without ccache. And lo and behold, this also helped. I dropped /var/tmp/ccache completely just to be safe, and now I have no issues building things anymore. So maybe the clang update really just screws with preexisting ccache...
Disabling ccache and even clearing the CCACHE_DIR didn't fix it for me. Dropping @gentoo-hardened and only building with -O2 remains the most reliable way on my systems. However it sometimes builds properly with different setups but I don't see any pattern behind it.
More comments about various workarounds are likely to mask the real issue. Something in Qt (or KDE Frameworks or Plasma) is being miscompiled by Clang. Voodoo to try avoid the miscompilation is not pertinent to figuring out what. It's useful to know if there's consistent facts about where it does happen and doesn't, but we don't need to enumerate guesses either. What would really help is if someone could put the time in to: 1. validating https://bugs.gentoo.org/865339#c21 (minimal set of packages needed for breakage) 2. try reproduce this in a clean stage3, with full instructions for how to trigger it and all steps taken from entering the chroot. You can use a chroot in /tmp/testing or something if you want. Qt 5 is really on life support for open source purposes and it's not easy to debug any of this. I want things to work with Clang, but I personally am not that invested in getting it working until we're onto Qt 6, given the build system hassle and difficulty with getting bugs fixed unless it impacts a paying customer for Qt 5. I'm not saying I don't care, but I'm saying that someone affected by this needs to put the work in to giving a reproducer as described above.
(In reply to Sam James from comment #32) > I'm not saying I don't care, but I'm saying that someone affected by this > needs to put the work in to giving a reproducer as described above. (or just use GCC until Qt 6.)
> minimal set of packages needed for breakage dev-qt/qtcore is definitely the main culprit here. Building the others with clang and with flags that would break qtcore still builds kde-frameworks/syntax-highlighting successfully. > try reproduce this in a clean stage3 Ok, I'll try to do this and report the results > just use GCC until Qt 6 Would be kind of annoying since I'm using libc++
(In reply to Jonas Rakebrandt from comment #34) If you can, please try use gcc for as much as possible (obviously), and libstdc++ for the lot, unless you determine libc++ is really needed for it (but obviously that has its own problems and makes things far more complicated given the amount of stuff you have to then rebuild). I think some of the reporters here were using libstdc++ so hopefully that's fine. > > > just use GCC until Qt 6 > Would be kind of annoying since I'm using libc++ I understand.
Created attachment 848757 [details] reproduced in clean chroot Looks like Qt really does have a problem with the hardening flags from >sys-devel/clang-common-15.0.6. Maybe qmake can't filter out problematic flags because they're only visible to clang?
(In reply to Jonas Rakebrandt from comment #36) > Created attachment 848757 [details] > reproduced in clean chroot > > Looks like Qt really does have a problem with the hardening flags from > >sys-devel/clang-common-15.0.6. > Maybe qmake can't filter out problematic flags because they're only visible > to clang? Would you mind poking at /etc/clang/gentoo-hardened.cfg and figuring out which one triggers it? You can comment out lines in there with # like normal.
Looks like -fstack-clash-protection is causing the issues. Building with all other flags simultaneously works (even with the harder optimization flags from previous tests) but as soon as it's added Qt is broken. Out of curiosity: Shouldn't -fstack-clash-protection be hardened exclusive anyways or is https://wiki.gentoo.org/wiki/Hardened/Toolchain#Changes just out of date?
(In reply to Jonas Rakebrandt from comment #38) > Looks like -fstack-clash-protection is causing the issues. Building with all > other flags simultaneously works (even with the harder optimization flags > from previous tests) but as soon as it's added Qt is broken. > Excellent work! > Out of curiosity: Shouldn't -fstack-clash-protection be hardened exclusive > anyways or is https://wiki.gentoo.org/wiki/Hardened/Toolchain#Changes just > out of date? I haven't updated that for the Clang position right now, I'll adjust it in a mo. Good catch.
Tested gcc with stack-clash-protection just to check and that seems to work fine. I also tried throwing -fno-stack-clash-protection into the CXXFLAGS for qtcore outside the chroot and that does indeed fix the issue. Now it even builds with -O3 and LTO again. However I'm not sure if other dev-qt/* packages may also be affected by the same issue. I guess we'll see if/when more reports roll in.
(In reply to Jonas Rakebrandt from comment #40) > Tested gcc with stack-clash-protection just to check and that seems to work > fine. > > I also tried throwing -fno-stack-clash-protection into the CXXFLAGS for > qtcore outside the chroot and that does indeed fix the issue. > Now it even builds with -O3 and LTO again. However I'm not sure if other > dev-qt/* packages may also be affected by the same issue. I guess we'll see > if/when more reports roll in. Fantastic. Could someone else who hit this bug confirm the same, just to ensure we're dealing with the same problem here?
I recompiled dev-qt/qtcore-5.15.8-r1, dev-qt/qtdeclarative-5.15.8-r2, dev-qt/qtxmlpatterns-5.15.8 and kde-frameworks/syntax-highlighting-5.102.0 without -fstack-clash-protection, and it built successfully! Thank you very much
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=92c1834342000220f71cf7e9b9ad0ed111d9e084 commit 92c1834342000220f71cf7e9b9ad0ed111d9e084 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-18 01:10:02 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-18 21:48:58 +0000 dev-qt/qtcore: pass -fno-stack-clash-protection with Clang With Clang, -fstack-clash-protection seems to lead to qtcore being miscompiled and e.g. kde-frameworks/syntax-highlighting failing to compile. It's hard to justify spending that much time investigating this for Qt 5 given it's likely it doesn't occur with Qt 6 (significant changes all over the place) and its build system is far more amenable to building with various sanitisers. Given this only happens with Clang, we can likely chalk this up to a Clang bug, but Qt is huge, and I don't have the time to try minimise this - help welcome if someone fancies it! This has probably been latent for quite a long time, but got exposed by sys-devel/clang-runtime recently starting to pass -fstack-clash-protection by default to match GCC's behaviour in Gentoo in the new upcoming (WIP) 23.0 profiles. Thanks in particular to Jonas Rakebrandt <xarblu@protonmail.com> for putting the work in to find the trigger. Bug: https://bugs.gentoo.org/865339 KDE-Bug: https://bugs.kde.org/show_bug.cgi?id=462084 KDE-Bug: https://bugs.kde.org/show_bug.cgi?id=464140 Signed-off-by: Sam James <sam@gentoo.org> dev-qt/qtcore/qtcore-5.15.8-r2.ebuild | 125 ++++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+)
*** Bug 887265 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee5aadc4bb62d5479d8bc31fa06eb2e5a1bbacc3 commit ee5aadc4bb62d5479d8bc31fa06eb2e5a1bbacc3 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-02-03 07:10:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-03 07:10:41 +0000 sys-devel/clang-common: drop -fstack-clash-protection There's very likely some Clang miscompilation occurring with -fstack-clash-protection, GCC's implementation is fine. Both qtcore and chromium have been reported to misbehave at runtime when built with Clang's. Drop it for now until we can look into it more or Clang gets fixed. Closes: https://bugs.gentoo.org/865339 Closes: https://bugs.gentoo.org/892537 Signed-off-by: Sam James <sam@gentoo.org> .../{clang-common-15.0.7-r1.ebuild => clang-common-15.0.7-r2.ebuild} | 3 ++- ...pre20230107-r1.ebuild => clang-common-16.0.0_pre20230107-r2.ebuild} | 3 ++- ....0_pre20230127.ebuild => clang-common-16.0.0_pre20230127-r1.ebuild} | 3 ++- ...lang-common-16.0.0_rc1.ebuild => clang-common-16.0.0_rc1-r1.ebuild} | 3 ++- 4 files changed, 8 insertions(+), 4 deletions(-)
