Summary: | dev-build/cmake: aborts with "std::bad_alloc" when configuring dev-qt/qtbase-6.8.1 if(?) built with clang on aarch64 and lto? (exact cause unknown) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | James Calligeros <jcalligeros99> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | esigra, ionen, jcalligeros99, kde, luke, qt, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 915000 | ||
Attachments: | build.log |
Description
James Calligeros
2024-12-04 04:42:32 UTC
Created attachment 913285 [details]
build.log
clang segfaulted? Are you still able to rebuild qtbase-6.7.3? emerge -1 "~dev-qt/qtbase-6.7.3" It could be something that's newly triggered with 6.8.1 by accident, but I'm getting the impression there's an issue with the toolchain rather than qtbase. You could try gcc too. Also, anything interest in dmesg? I'm not sure which executable resulted in that "(core dumped)" =dev-qt/qtbase-6.7.3-r2 builds and merges successfully with clang and gcc. Using gcc on 6.8.1 results in the same failure. Nothing interesting in dmesg either. I know that sam did manage to build qtbase-6.8.1 w/ gcc on aarch64 given was testing qtwebengine-6.8.1 there, so it's probably due to something special here (*FLAGS, llvm- tools usage, etc...). I did try to build with a "similar" toolchain layout on amd64 but it's fine there, probably(?) either aarch64-specific or these machines in particular (but I can't test myself, so I have no idea). CC'ing sam in case happen to have an idea Wonder if it's actually cmake that's aborting? With the error appearing like this I think it could. Just in case, does anything change if you rebuild cmake with gcc and C(XX)FLAGS=-O2 + default LDFLAGS? I had rebuilt cmake before filing the bug, but I just did it again with my gcc env and... Yep, that did it :) I may have time to investigate later, but since clang's -O3 doesn't include any "risky" optimisations and I don't use -ffast-math or anything like that I think it could be LTO behaviour. Nice, guess I'll re-assign to cmake for now. I'll take a look but I can't promise to run it down all the way at least for a few days. I can't reproduce it with CFLAGS="-O3 -fPIC -mbranch-protection=standard -march=native -flto=thin" CXXFLAGS="-O3 -fPIC -mbranch-protection=standard -march=native -flto" LDFLAGS="-Wl,-O1" CC=clang CXX=clang++ emerge -v1 cmake && emerge -v1 qtwebengine on neoverse-n1 and so can't do anything here. (In reply to Sam James from comment #13) > I can't reproduce it with CFLAGS="-O3 -fPIC -mbranch-protection=standard > -march=native -flto=thin" CXXFLAGS="-O3 -fPIC -mbranch-protection=standard > -march=native -flto" LDFLAGS="-Wl,-O1" CC=clang CXX=clang++ emerge -v1 cmake > && emerge -v1 qtwebengine on neoverse-n1 and so can't do anything here. It's qtbase that's failing (my comment may have been misleading when I said qtwebengine given I meant -> "this means did qtbase too"). (In reply to Ionen Wolkens from comment #14) > (In reply to Sam James from comment #13) > CXXFLAGS="-O3 -fPIC -mbranch-protection=standard -march=native -flto" fwiw may want to use =thin for CXXFLAGS too if that can change anything, CFLAGS are barely used by cmake. LDFLAGS has a few things too, albeit I doubt these could change much (already need lld for =thin, so that means it's being used through default-lld anyway). Ah, thank you! Fixed both inconsistent CXXFLAGS (added =thin) and tried qtbase but no luck. I'll try LDFLAGS given getting nowhere but I don't expect it to make a difference. James, I can give guidance for narrowing it down at least, just can't actually debug it. |