* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
@ 2020-11-19 19:15 ` tnfchris at gcc dot gnu.org
2020-11-19 19:47 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2020-11-19 19:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tnfchris at gcc dot gnu.org
Host|powerpc64le-linux-gnu |powerpc64le-linux-gnu,
| |aarch64-none-linux-gnu
Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu,
| |aarch64-none-linux-gnu
Build|powerpc64le-linux-gnu |powerpc64le-linux-gnu,
| |aarch64-none-linux-gnu
--- Comment #1 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
I get an equally weird error during make-install for aarch64-none-linux-gnu:
../libbacktrace/.libs/libbacktrace.a(mmap.o): In function `backtrace_free':
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/mmap.c:229:
undefined reference to `__aarch64_swp4_acq'
../libbacktrace/.libs/libbacktrace.a(mmap.o): In function
`backtrace_alloc':
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/mmap.c:135:
undefined reference to `__aarch64_swp4_acq'
../libbacktrace/.libs/libbacktrace.a(elf.o): In function
`elf_add_syminfo_data':
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/elf.c:746:
undefined reference to `__aarch64_cas8_acq_rel'
../libbacktrace/.libs/libbacktrace.a(elf.o): In function
`backtrace_initialize':
../.././gcc/lto/Make-lang.in:100: recipe for target 'lto-dump' failed
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/elf.c:4906:
undefined reference to `__aarch64_cas8_acq_rel'
../libbacktrace/.libs/libbacktrace.a(dwarf.o): In function
`backtrace_dwarf_add':
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/dwarf.c:4045:
undefined reference to `__aarch64_cas8_acq_rel'
collect2: error: ld returned 1 exit status
make[2]: *** [lto-dump] Error 1
../libbacktrace/.libs/libbacktrace.a(mmap.o): In function `backtrace_free':
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/mmap.c:229:
undefined reference to `__aarch64_swp4_acq'
../libbacktrace/.libs/libbacktrace.a(mmap.o): In function
`backtrace_alloc':
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/mmap.c:135:
undefined reference to `__aarch64_swp4_acq'
../libbacktrace/.libs/libbacktrace.a(elf.o): In function
`elf_add_syminfo_data':
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/elf.c:746:
undefined reference to `__aarch64_cas8_acq_rel'
../libbacktrace/.libs/libbacktrace.a(elf.o): In function
`backtrace_initialize':
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/elf.c:4906:
undefined reference to `__aarch64_cas8_acq_rel'
../.././gcc/cp/Make-lang.in:121: recipe for target 'cc1plus' failed
../libbacktrace/.libs/libbacktrace.a(dwarf.o): In function
`backtrace_dwarf_add':
make[2]: Leaving directory '/host-aarch64-unknown-linux-gnu/gcc'
/host-aarch64-unknown-linux-gnu/libbacktrace/../.././libbacktrace/dwarf.c:4045:
undefined reference to `__aarch64_cas8_acq_rel'
collect2: error: ld returned 1 exit status
make[2]: *** [cc1plus] Error 1
Makefile:5133: recipe for target 'install-gcc' failed
make[1]: Leaving directory ''
make[1]: *** [install-gcc] Error 2
Makefile:2446: recipe for target 'install' failed
make: *** [install] Error 2
etc for each install target. I have only been able to reproduce it when
bootstrap enabled and haven't been able to on Ubuntu 18.04 but can on Debian
9..
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
2020-11-19 19:15 ` [Bug other/97911] " tnfchris at gcc dot gnu.org
@ 2020-11-19 19:47 ` jakub at gcc dot gnu.org
2020-11-19 23:21 ` tnfchris at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-19 19:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Please see https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559605.html
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
2020-11-19 19:15 ` [Bug other/97911] " tnfchris at gcc dot gnu.org
2020-11-19 19:47 ` jakub at gcc dot gnu.org
@ 2020-11-19 23:21 ` tnfchris at gcc dot gnu.org
2020-11-19 23:24 ` ebotcazou at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2020-11-19 23:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #3 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks Jakub, that patch does seem to fix the AArch64 build.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2020-11-19 23:21 ` tnfchris at gcc dot gnu.org
@ 2020-11-19 23:24 ` ebotcazou at gcc dot gnu.org
2020-11-19 23:30 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2020-11-19 23:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Target Milestone|--- |11.0
Last reconfirmed| |2020-11-19
--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
See also https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559580.html
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2020-11-19 23:24 ` ebotcazou at gcc dot gnu.org
@ 2020-11-19 23:30 ` jakub at gcc dot gnu.org
2020-11-20 7:50 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-19 23:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Even that should be fixed by the patch I've posted.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2020-11-19 23:30 ` jakub at gcc dot gnu.org
@ 2020-11-20 7:50 ` cvs-commit at gcc dot gnu.org
2020-11-20 7:51 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-20 7:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:a774a6a2fbeaf7cbcb7a7afe433418f2d740b45b
commit r11-5190-ga774a6a2fbeaf7cbcb7a7afe433418f2d740b45b
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Nov 20 08:45:11 2020 +0100
configury: Fix up --enable-link-serialization support
Eric reported that the --enable-link-serialization changes seemed to
cause the binaries to be always relinked, for example from the
gcc/ directory of the build tree:
make
[relink of gnat1, brig1, cc1plus, d21, f951, go1, lto1, ...]
make
[relink of gnat1, brig1, cc1plus, d21, f951, go1, lto1, ...]
Furthermore as reported in PR, it can cause problems during make install
where make install rebuilds the binaries again.
The problem is that for make .PHONY targets are just
"rebuilt" always, so it is very much undesirable for the cc1plus$(exeext)
etc. dependencies to include .PHONY targets, but I was using
them - cc1plus.prev which would depend on some *.serial and
e.g. cc1.serial depending on c and c depending on cc1$(exeext).
The following patch rewrites this so that *.serial and *.prev aren't
.PHONY targets, but instead just make variables.
I was worried that the order in which the language makefile fragments are
included (which is quite random, what order we get from the filesystem
matching */config-lang.in) would be a problem but it seems to work fine
- as it uses make = rather than := variables, later definitions are just
fine for earlier uses as long as the uses aren't needed during the
makefile parsing, but only in the dependencies of make targets and in
their commands.
2020-11-20 Jakub Jelinek <jakub@redhat.com>
PR other/97911
gcc/
* configure.ac: In SERIAL_LIST use lang words without .serial
suffix. Change $lang.prev from a target to variable and instead
of depending on *.serial expand to the *.serial variable if
the word is in the SERIAL_LIST at all, otherwise to nothing.
* configure: Regenerated.
gcc/c/
* Make-lang.in (c.serial): Change from goal to a variable.
(.PHONY): Drop c.serial.
gcc/ada/
* gcc-interface/Make-lang.in (ada.serial): Change from goal to a
variable.
(.PHONY): Drop ada.serial and ada.prev.
(gnat1$(exeext)): Depend on $(ada.serial) rather than ada.serial.
gcc/brig/
* Make-lang.in (brig.serial): Change from goal to a variable.
(.PHONY): Drop brig.serial and brig.prev.
(brig1$(exeext)): Depend on $(brig.serial) rather than brig.serial.
gcc/cp/
* Make-lang.in (c++.serial): Change from goal to a variable.
(.PHONY): Drop c++.serial and c++.prev.
(cc1plus$(exeext)): Depend on $(c++.serial) rather than c++.serial.
gcc/d/
* Make-lang.in (d.serial): Change from goal to a variable.
(.PHONY): Drop d.serial and d.prev.
(d21$(exeext)): Depend on $(d.serial) rather than d.serial.
gcc/fortran/
* Make-lang.in (fortran.serial): Change from goal to a variable.
(.PHONY): Drop fortran.serial and fortran.prev.
(f951$(exeext)): Depend on $(fortran.serial) rather than
fortran.serial.
gcc/go/
* Make-lang.in (go.serial): Change from goal to a variable.
(.PHONY): Drop go.serial and go.prev.
(go1$(exeext)): Depend on $(go.serial) rather than go.serial.
gcc/jit/
* Make-lang.in (jit.serial): Change from goal to a
variable.
(.PHONY): Drop jit.serial and jit.prev.
($(LIBGCCJIT_FILENAME)): Depend on $(jit.serial) rather than
jit.serial.
gcc/lto/
* Make-lang.in (lto1.serial, lto2.serial): Change from goals to
variables.
(.PHONY): Drop lto1.serial, lto2.serial, lto1.prev and lto2.prev.
($(LTO_EXE)): Depend on $(lto1.serial) rather than lto1.serial.
($(LTO_DUMP_EXE)): Depend on $(lto2.serial) rather than
lto2.serial.
gcc/objc/
* Make-lang.in (objc.serial): Change from goal to a variable.
(.PHONY): Drop objc.serial and objc.prev.
(cc1obj$(exeext)): Depend on $(objc.serial) rather than
objc.serial.
gcc/objcp/
* Make-lang.in (obj-c++.serial): Change from goal to a variable.
(.PHONY): Drop obj-c++.serial and obj-c++.prev.
(cc1objplus$(exeext)): Depend on $(obj-c++.serial) rather than
obj-c++.serial.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2020-11-20 7:50 ` cvs-commit at gcc dot gnu.org
@ 2020-11-20 7:51 ` jakub at gcc dot gnu.org
2020-11-20 7:53 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-20 7:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2020-11-20 7:51 ` jakub at gcc dot gnu.org
@ 2020-11-20 7:53 ` jakub at gcc dot gnu.org
2020-11-20 16:06 ` seurer at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-20 7:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
` (7 preceding siblings ...)
2020-11-20 7:53 ` jakub at gcc dot gnu.org
@ 2020-11-20 16:06 ` seurer at gcc dot gnu.org
2021-09-27 22:42 ` ldalessandro at gmail dot com
2021-09-27 22:46 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: seurer at gcc dot gnu.org @ 2020-11-20 16:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #9 from seurer at gcc dot gnu.org ---
Thanks! It is indeed working again.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
` (8 preceding siblings ...)
2020-11-20 16:06 ` seurer at gcc dot gnu.org
@ 2021-09-27 22:42 ` ldalessandro at gmail dot com
2021-09-27 22:46 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: ldalessandro at gmail dot com @ 2021-09-27 22:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
Luke Dalessandro <ldalessandro at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ldalessandro at gmail dot com
--- Comment #10 from Luke Dalessandro <ldalessandro at gmail dot com> ---
I'm seeing this wtih gcc-11.2 on an x86_64-pc-linux-gnu system (RHEL 8.4)
installed using spack. What is the right way for me to find out if this is an
actual gcc regression or a packaging problem?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
2020-11-19 16:42 [Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142 seurer at gcc dot gnu.org
` (9 preceding siblings ...)
2021-09-27 22:42 ` ldalessandro at gmail dot com
@ 2021-09-27 22:46 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-27 22:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Luke Dalessandro from comment #10)
> I'm seeing this wtih gcc-11.2 on an x86_64-pc-linux-gnu system (RHEL 8.4)
> installed using spack. What is the right way for me to find out if this is
> an actual gcc regression or a packaging problem?
It is definitely unrelated to this issue. Can you file a seperate bug with all
the needed information listed on https://gcc.gnu.org/bugs/ ?
^ permalink raw reply [flat|nested] 12+ messages in thread