Created attachment 884790 [details] build log so this happened the other day: bootstrap complete. rebuilding... Traceback (most recent call last): File "/var/tmp/portage/dev-build/ninja-1.11.1-r5/work/ninja-1.11.1/configure.py", line 720, in <module> subprocess.check_call(rebuild_args) File "/usr/lib/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['./ninja', '-v']' died with <Signals.SIGSEGV: 11>. dev-build/ninja-1.11.1-r3 and -r4 are just fine, the only difference between r4 and r5 is the cpp flags patch. the full build log is attached in armv7a chroot on the same machine, the build was just fine
Created attachment 884791 [details] output from emerge --info
emerge -pv dev-build/ninja for completness: These are the packages that would be merged, in order: [ebuild U ] dev-build/ninja-1.11.1-r5::gentoo [1.11.1-r4::gentoo] USE="-doc -test" 0 KiB Total: 1 package (1 upgrade), Size of downloads: 0 KiB
Not yet clear why it's going wrong, as the flags added by append-lfs-flags should do nothing on arm64. Could you try to get a backtrace from the crashing ninja process (run it with gdb --args ...), and also get the build.log for -r4?
Created attachment 884873 [details] compressed build log of -r4
I'm emerging gdb on the machine, can you be so kind and help me with the full command I need to execute when debugging it? Don't have any experience of throwing a python build system into it, thanks.
yes ofc, let me make it crash artificially here so I can give full steps, please hold...
Created attachment 884879 [details, diff] debugme.patch OK, apply this to dev-build/ninja. Build it with -ggdb3 (see https://wiki.gentoo.org/wiki/Debugging#Per-package). Then when it crashes, go into the workdir, run the command after 'debug me with:', then when gdb opens: r (hit enter) bt (hit enter) show the output?
I come back to this within the next week (propably), and I can't find the bug anymore via the opened bugs by me function of bugzilla.
Use a bookmark or something.
so, the command which fails and gives a segfault is a simple ./ninja -v , where the ninja binary is the one which was bootstrapped by the ebuild
We need a backtrace per comment 7.
Created attachment 885551 [details] output from gdb
Hmm, so it is failing some where in the standard vector class when something is getting pushed via std::vector::push_back. Your GCC seems to be a bit out of date, so I wonder if this is a toolchain bug.
Adding toolchain.
try building it with -D_GLIBCXX_ASSERTIONS - it is quite not impossible that the program violates some precondition of the standard. I don't have GCC 11 sources on hand to investigate further, but that flag alone should belp a lot
(In reply to Arsen Arsenović from comment #15) > try building it with -D_GLIBCXX_ASSERTIONS - it is quite not impossible that > the program violates some precondition of the standard. > > I don't have GCC 11 sources on hand to investigate further, but that flag > alone should belp a lot There's https://github.com/ninja-build/ninja/issues/2309 ...
(In reply to Arsen Arsenović from comment #15) > try building it with -D_GLIBCXX_ASSERTIONS - it is quite not impossible that > the program violates some precondition of the standard. hi, you were right and this got me a working =dev-build/ninja-1.11.1-r5: cat /etc/portage/env/dev-build/ninja CXXFLAGS="${CXXFLAGS} -D_GLIBCXX_ASSERTIONS"
It wasn't supposed to! It was supposed to give a better error message so it crashed earlier.
(In reply to Sam James from comment #16) > There's https://github.com/ninja-build/ninja/issues/2309 ... interesting, tt_1, what path are you operating under? I have GCC11 now so I'll try reproducing
(In reply to Arsen Arsenović from comment #19) > (In reply to Sam James from comment #16) > > There's https://github.com/ninja-build/ninja/issues/2309 ... > > interesting, tt_1, what path are you operating under? I have GCC11 now so > I'll try reproducing there is nothing really special about the path, the bootstrapped binary can be found within portage tempdir in /var/tmp/portage/dev-build/ninja-1.11.1-r5/work/ninja-1.11.-r5/ or do you want to see what my env is?
I was able to solve this issue by upgrading to gcc-12, and failed to track down where this possibly could have been fixed for a possible backport.
