Running `bootstrap-prefix.sh` on Gentoo errors in stage3 build with error Segmentation Fault Reproducible: Always Steps to Reproduce: 1.Running bootstrap-prefix.sh 2. 3.
Created attachment 766976 [details] gcc build log
I'm hitting this too on Ubuntu 21.10.
What about GCC 10.3.0?
time to drop this version from the tree?
I retried on GCC-11.2.1 and the segmentation fault is still there.
so, this is on a Gentoo Linux host?
Yes
I think the problem could be not with the GCC being built, but the one building it. I'm having trouble to build older GCC versions (i.e. 6 through 10) with GCC 11 in Gentoo as of recent. Maybe if we force the bootstrap to build using an older GCC (i.e. 9 or earlier) it might work.
The quick fix for now would be to echo the working gcc version in "$EPREFIX/etc/portage/package.mask"
I tried building older gcc versions and just like Amadio said they dont build. So kindly ignore my Comment 9, I misread. Is it feasible that prefix downloads gcc binaries and then build gcc ? As I believe asking the host system to downgrade gcc is less feasible.
(In reply to Atharva from comment #10) > I tried building older gcc versions and just like Amadio said they dont > build. So kindly ignore my Comment 9, I misread. Is it feasible that prefix > downloads gcc binaries and then build gcc ? As I believe asking the host > system to downgrade gcc is less feasible. Eh, not really. We're better off figuring out what the issue is with host GCC and working around it. This happens for me even with Ubuntu's latest GCC which is suspicious.
Hi, Also hit by this bug, and got some hints: Segfault is caused by strcmp between hardcoded value and uninitialised value (processor_alias_table), in gcc/config/i386/i386-options.c:ix86_option_override_internal (line 1986). processor_alias_table is supposed to be initialised in gcc/common/config/i386/i386-common.h, but (likely related to C++ init semantics, pta being a class, processor_alias_table being an array of pta), there is only a zero-initialised room here at strcmp time. I might dive forward into this, but i feel very uncomfortable with gcc innards. Also, it might be time to promote this bug as confirmed. Regards
(In reply to Étienne Buira from comment #12) (fwiw, confirmed vs unconfirmed doesn't make much difference to developers usually, but happy to do so).
*** Bug 845051 has been marked as a duplicate of this bug. ***
I find it interesting that the compiler crashes during stage3 even if a full bootstrap (removing --disable-bootstrap and GCC_MAKE_TARGET from the script) succeeds during stage2. Doesn't a full bootstrap ensure that the compiler is compiled with itself, and can build itself properly?
I haven't had time to properly debug this besides trying to build it from time to time, but I recently had the time to update my host machine to glibc 2.35 (and complete the python3.10 migration), and trying to build gentoo prefix again, it gets through stage 3 flawlessly. I suspect the issue was that the prefix was building a newer version of glibc than the one on the host, and something from the system was being used incorrectly. I suspect include paths are ordered incorrectly, but I haven't been able to prove this. While glibc-2.34 is still in the tree, I wonder if anyone can build a modern gentoo chroot with this version but everything else modern, and reproduce the issue again. It'd be good to find out *what* broke before it hits people on certain distributions or with a future glibc upgrade again.
on CentOS-8.3 I see GCC installing, but afterwards it is uselessL configure:4395: x86_64-pc-linux-gnu-gcc -O2 -pipe -O2 -pipe -L/bootstrap64-20220809/usr/lib64 -Wl,--dynamic-linker=/bootstrap64-20220809/lib64/ld-linux-x86-64.so.2 conftest.c >&5 /bootstrap64-20220809/tmp/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: /lib/../lib64/Scrt1.o: in function `_start': (.text+0x16): undefined reference to `__libc_csu_fini' /bootstrap64-20220809/tmp/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: (.text+0x1d): undefined reference to `__libc_csu_init' $ /lib64/libc.so.6 GNU C Library (GNU libc) stable release version 2.28. Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 8.3.1 20191121 (Red Hat 8.3.1-5). libc ABIs: UNIQUE IFUNC ABSOLUTE For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. $ ./bootstrap64-20220809/lib64/libc.so.6 GNU C Library (Gentoo 2.35-r8 p9) stable release version 2.35. Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 10.3.1 20211126. libc ABIs: UNIQUE IFUNC ABSOLUTE For bug reporting instructions, please see: <https://bugs.gentoo.org/>.
Need to try what was suggested in bug 824482 but I don't have an environment setup. I suspect slyfox nailed it as he hit something very similar in nix.
> > Or mechanically change https://gitweb.gentoo.org/repo/proj/prefix.git/plain/scripts/bootstrap-prefix.sh > > from > export LDFLAGS="-L${ROOT}/usr/$(get_libdir) -Wl,--dynamic-linker=${RAP_DLINKER}" > to > export LDFLAGS="-B${ROOT}/usr/$(get_libdir) -L${ROOT}/usr/$(get_libdir) -Wl,--dynamic-linker=${RAP_DLINKER}" Oh. That's easy, let me try that.
* strip-flags: LDFLAGS: changed '-B/bootstrap64-20220810/usr/lib64 -L/bootstrap64-20220810/usr/lib64' to '-L/bootstrap64-20220810/usr/lib64' Ok, so that doesn't work.
USE=custom-cflags may help although obviously you can just hack at the eclass. If it works, we can add in some cheesy check for if we're bootstrapping a prefix and skip.
(although thinking about it, this is so specific that we could probably skip it in strip-flags as if someone's setting it, they probably really mean it!)
(In reply to Sam James from comment #21) > USE=custom-cflags may help although obviously you can just hack at the > eclass. > > If it works, we can add in some cheesy check for if we're bootstrapping a > prefix and skip. tc_version_is_at_least 11 && IUSE+=" custom-cflags" so I guess that's no too, we can only hack the eclass.
What I don't get, Scrt1.o is on Gentoo in /usr/lib64/Scrt1.o, on CentOS in /lib64/Scrt1.o. Why does the compiler find the host one, doesn't it expect it in /usr, or even better use the one from the Prefix?
(In reply to Fabian Groffen from comment #24) > What I don't get, Scrt1.o is on Gentoo in /usr/lib64/Scrt1.o, on CentOS in > /lib64/Scrt1.o. Why does the compiler find the host one, doesn't it expect > it in /usr, or even better use the one from the Prefix? Not sure it's relevant, but last time i looked at this, the dynamic runtime expanded to two filenames (one libc, one lsb that actually referred to the same file), and thus one were interpreted as dynamic loader option, the other as a mere input file.
These versions are long gone.
