Summary: | dev-util/qbs-2.3.1 fails to compile: basemessage.cpp:(.text+0x180): undefined reference to qbs::Internal::writeAssertLocation(char const, char const, int) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ionen, toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 914580 | ||
Attachments: | build.log |
Description
Agostino Sarubbo
2024-05-30 10:26:12 UTC
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. |