https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-util/qbs-2.3.1 fails to compile. Discovered on: amd64 (internal ref: gcc14_tinderbox) System: GCC-14-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#GCC-14) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0014
Created attachment 894651 [details] build.log build log and emerge --info
Error(s) that match a know pattern in addition to what has been reported in the summary: FAILED: bin/qbs_lspclient basemessage.cpp:(.text+0x180): undefined reference to `qbs::Internal::writeAssertLocation(char const*, char const*, int)' languagefeatures.cpp:(.text+0x5f44): undefined reference to `qbs::Internal::writeAssertLocation(char const*, char const*, int)' languagefeatures.cpp:(.text._ZNK3lsp8ResponseINS_11HoverResultEDnE7isValidEP7QString[_ZNK3lsp8ResponseINS_11HoverResultEDnE7isValidEP7QString]+0xd4): undefined reference to `qbs::Internal::writeAssertLocation(char const*, char const*, int)' languagefeatures.cpp:(.text._ZNK3lsp8ResponseINS_19LanguageClientValueINS_13SignatureHelpEEEDnE7isValidEP7QString[_ZNK3lsp8ResponseINS_19LanguageClientValueINS_13SignatureHelpEEEDnE7isValidEP7QString]+0xd4): undefined reference to `qbs::Internal::writeAssertLocation(char const*, char const*, int)' languagefeatures.cpp:(.text._ZNK3lsp9MessageId7isValidEv[_ZNK3lsp9MessageId7isValidEv]+0x38): undefined reference to `qbs::Internal::writeAssertLocation(char const*, char const*, int)' collect2: error: ld returned 1 exit status
Hm, can't reproduce. Or at least not with gcc-14.1.1_p20240518 (see 0525 is used here). Guess I'll try updating given don't see what else might affect this at a glance.
Nope that wasn't it, don't have more ideas at the moment but will try experimenting more later.
Oh.. I wasn't really suspecting it but it fails with -O3 + gcc-14? (-O3 is fine with gcc-13, albeit I tested in a different chroot to avoid libstdc++ downgrade) CC'ing toolchain given this sounds odd. Guess I'll filter it back to -O2 for the time being anyhow.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=45c54345133147897f4ec949343b15a395d31e08 commit 45c54345133147897f4ec949343b15a395d31e08 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-05-30 15:20:11 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-05-30 15:52:06 +0000 dev-util/qbs: add workaround for gcc:14 + -O3 build failure Exact cause unknown, but no harm in doing this for now. Does not seem needed for neither gcc:13 nor clang. For anyone trying to reproduce, don't forget to drop this. Bug: https://bugs.gentoo.org/933187 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-util/qbs/qbs-2.3.1.ebuild | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
ftr I don't intend to spend more time than necessary on this package (was tempted to last rite it before), so just keeping the s/-O3/-O2/ to avoid headaches is good enough for me. But worried it may be exposing a potential regression in gcc:14 w/ -O3 given gcc:13 is fine which would be more important. Not to say it may not just be something weird qbs is doing that just now surface as an issue with new optimizations.
does this still affect 2.4.2 ?
(In reply to Andreas K. Hüttel from comment #8) > does this still affect 2.4.2 ? Yes, but it's worked around so this doesn't block anything.
Continues to fail with gcc-14.2.1_p20241221 and qbs-2.5.0
(In reply to NHO from comment #10) > Continues to fail with gcc-14.2.1_p20241221 and qbs-2.5.0 You mean without the workaround, or failing as-is? (ftr I've already tried removing it with 2.5.0 and it indeed does fail)
I'll have a look, I missed this one before.
I meant it fails without workaround, ran it to verify bug for myself.
It only happens with -Wl,--as-needed. qbs::Internal::writeAssertLocation is provided by qbsassert.cpp.o inside libqbscore.so and basemessage.cpp.o is listed afterwards inside libqtclsp.a. I wonder if with -O3, it just decides not to inline use of writeAssertLocation, which is why this becomes a problem.
It's difficult to reduce and bisect because of C++20 (which is still experimental) and the use of builtin traits which can only be disabled with GCC 14 and newer (can't use 13-preprocessed source w/ c++20 with 14+). But I'm inclined to say that it worked by luck before given the ordering is wrong + as-needed?
(In reply to Sam James from comment #15) > It's difficult to reduce and bisect because of C++20 (which is still > experimental) and the use of builtin traits which can only be disabled with > GCC 14 and newer (can't use 13-preprocessed source w/ c++20 with 14+). But > I'm inclined to say that it worked by luck before given the ordering is > wrong + as-needed? Failing command: /usr/bin/x86_64-pc-linux-musl-g++ -O3 -pipe -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs tests/lspclient/CMakeFiles/qbs_lspclient.dir/qbs_lspclient_autogen/mocs_compilation.cpp.o tests/lspclient/CMakeFiles/qbs_lspclient.dir/lspclient.cpp.o -o bin/qbs_lspclient -Wl,-rpath,"\$ORIGIN/../lib:/var/tmp/portage/dev-util/qbs-2.5.0/work/qbs-src-2.5.0_build/lib:" lib/libqbscore.so.2.5.0 lib/libqtclsp.a /usr/lib/libQt6Network.so.6.8.1 /usr/lib/libQt6Core5Compat.so.6.8.1 /usr/lib/libQt6Core.so.6.8.1 Working command: /usr/bin/x86_64-pc-linux-musl-g++ -O3 -pipe -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs tests/lspclient/CMakeFiles/qbs_lspclient.dir/qbs_lspclient_autogen/mocs_compilation.cpp.o tests/lspclient/CMakeFiles/qbs_lspclient.dir/lspclient.cpp.o -o bin/qbs_lspclient -Wl,-rpath,"\$ORIGIN/../lib:/var/tmp/portage/dev-util/qbs-2.5.0/work/qbs-src-2.5.0_build/lib:" lib/libqtclsp.a lib/libqbscore.so.2.5.0 /usr/lib/libQt6Network.so.6.8.1 /usr/lib/libQt6Core5Compat.so.6.8.1 /usr/lib/libQt6Core.so.6.8.1 (just swapping position of libqbscore.so.2.5.0)
I'm going to leave it at that unless really need to look more given the above (difficulty in reducing/investigating further, seemingly valid explanation).
