Bug 549326 – <sys-devel/gdb-7.10: sim doesn't build w/gcc-5.1

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Joshua Kinard 2015-05-13 03:01:33 UTC]

At least, I think this is gcc-5.1.x-related.  Had gdb working under 4.9.2.

This is on a cross-target of 'mips64-unknown-linux-gnu' on an x86_64 systems.

Build dies when building libsim.a due to multiple definitions of 'sim_addr_range_hit_p'.  already tried building without LTO and no dice.  Graphite is already disabled for GDB.

Exact error (truncated for brevity):

x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H     -DPROFILE=1 -DWITH_PROFILE=-1   -DWITH_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_TARGET_WORD_BITSIZE=64 -DWITH_TARGET_WORD_MSB=63 -DWITH_DEFAULT_TARGET_BYTE_ORDER=BIG_ENDIAN  -DWITH_FLOATING_POINT=HARD_FLOATING_POINT -DWITH_HW=0 -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN    -DWITH_RESERVED_BITS=1  -DWITH_SMP=0  -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral    -DMIPS_MACH_DEFAULT=bfd_mach_mips8000   -I. -I. -I../common -I./../common -I../../include -I./../..//include -I../../bfd -I./../..//bfd -I../../opcodes -I./../..//opcodes  -O2 -march=corei7 -mtune=corei7 -mfpmath=sse -msse -msse2 -mssse3 -msse4.1 -msse4.2 -mcx16 -msahf -mcrc32 -maccumulate-outgoing-args -fforce-addr -fmodulo-sched -fivopts -ftree-loop-im -ftree-loop-linear -ftree-loop-ivcanon -fgcse-after-reload -fgcse-lm -fgcse-sm -fgcse-las -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -flto=8 -fuse-linker-plugin -fno-loop-interchange -fno-tree-loop-distribution -fno-loop-strip-mine -fno-loop-block -static-libstdc++ -static-libgcc -O2 -march=corei7 -mtune=corei7  -mfpmath=sse -msse -msse2 -mssse3 -msse4.1 -msse4.2  -mcx16 -msahf -mcrc32 -maccumulate-outgoing-args  -fforce-addr -fmodulo-sched -fivopts  -ftree-loop-im -ftree-loop-linear -ftree-loop-ivcanon  -fgcse-after-reload -fgcse-lm -fgcse-sm -fgcse-las  -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block  -ftree-vectorize -flto=8 -fuse-linker-plugin -Wl,-z,now -Wl,-z,relro -fno-loop-interchange -fno-tree-loop-distribution -fno-loop-strip-mine -fno-loop-block -o run \
  nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a  ../../libiberty/libiberty.a -lm -ldl -lz -lnsl
sim-config.o (symbol from plugin): In function `sim_addr_range_hit_p':
(.text+0x0): multiple definition of `sim_addr_range_hit_p'
nrun.o (symbol from plugin):(.text+0x0): first defined here
sim-io.o (symbol from plugin): In function `sim_io_write_stdout':
(.text+0x0): multiple definition of `sim_addr_range_hit_p'
nrun.o (symbol from plugin):(.text+0x0): first defined here
sim-info.o (symbol from plugin): In function `sim_info':
(.text+0x0): multiple definition of `sim_addr_range_hit_p'
nrun.o (symbol from plugin):(.text+0x0): first defined here
<truncated>

-----

Exact build commands, in order (needed because of a bug in glibc):
stage2:
crossdev --b 2.25 --g 5.1.0 --l 2.21 --k 4.0 -s2 -A n32 -t mips64-unknown-linux-gnu --without-headers -v

stage3:
ASFLAGS="-march=mips4 -mtune=mips4" LDFLAGS="-Wl,-z,now -Wl,-z,relro" CFLAGS="-O2 -pipe -march=mips4 -mtune=mips4 -mplt -fivopts -fforce-addr -fmodulo-sched -ftree-vectorize" CPPFLAGS="-O2 -pipe -march=mips4 -mtune=mips4 -mplt -fivopts -fforce-addr -fmodulo-sched -ftree-vectorize" crossdev --b 2.25 --g 5.1.0 --l 2.21 --k 4.0 -s3 -A n32 -t mips64-unknown-linux-gnu --without-headers -v

stage4:
USE="-sanitize" crossdev --b 2.25 --g 5.1.0 --l 2.21 --k 4.0 -s4 -A n32 --ex-gdb -t mips64-unknown-linux-gnu --without-headers -v

-----

Ironically, Google only returns two hits on mailing lists for this problem:

1. https://sourceware.org/ml/gdb/2015-02/msg00031.html
2. https://sourceware.org/ml/gdb/2015-03/msg00085.html

Tried -std=c89 in the host CFLAGS as well as MAKEOPTS=-j1.  No luck on either idea.  Finally got it to merge by using -std=gnu89 instead (hang up w/ c89 seems to be C++-style comments in C code).

[Comment 1 SpanKY 2015-05-14 16:44:25 UTC]

i fixed gcc-5 build errors in upstream with:
5a394431deb3745c04a74d2a109aca075f79afd6
2b6ca06237301286016acc4b7bbf5338a27fd5fc
92fc6153a6fdf2a027d9780f5945712aafad4a9e

although i think for mips you just need that last one.  they're looking at branching the next gdb soonish, so i'd rather be lazy and just wait for that.  if you filed this bug like 48 hours ago i could have gotten those merged into the 7.9 branch in time for 7.9.1 :P.  i forgot about backporting sometimes.

[Comment 2 Joshua Kinard 2015-05-15 20:48:13 UTC]

(In reply to SpanKY from comment #1)
> i fixed gcc-5 build errors in upstream with:
> 5a394431deb3745c04a74d2a109aca075f79afd6
> 2b6ca06237301286016acc4b7bbf5338a27fd5fc
> 92fc6153a6fdf2a027d9780f5945712aafad4a9e
> 
> although i think for mips you just need that last one.  they're looking at
> branching the next gdb soonish, so i'd rather be lazy and just wait for
> that.  if you filed this bug like 48 hours ago i could have gotten those
> merged into the 7.9 branch in time for 7.9.1 :P.  i forgot about backporting
> sometimes.

If we can carry the backported patch in the tree until it can go upstream, that'll work fine for me.

[Comment 3 SpanKY 2015-05-16 03:43:03 UTC]

(In reply to Joshua Kinard from comment #2)

there's nothing to go upstream ;).  all the commits i referenced are in upstream already and will be in the next release.  it's a question of spending the time backporting or just waiting for the next gdb release.

[Comment 4 Joshua Kinard 2015-05-16 07:42:36 UTC]

(In reply to SpanKY from comment #3)
> (In reply to Joshua Kinard from comment #2)
> 
> there's nothing to go upstream ;).  all the commits i referenced are in
> upstream already and will be in the next release.  it's a question of
> spending the time backporting or just waiting for the next gdb release.

Can we carry the backport in *our* tree then until the next release of GDB?

[Comment 5 SpanKY 2015-05-16 12:58:54 UTC]

(In reply to Joshua Kinard from comment #4)

yes, it shouldn't be too hard to do that.  i'm asking if you really want this now or if you can wait until the 7.10 release which is slated for June.

[Comment 6 Joshua Kinard 2015-07-22 07:18:03 UTC]

(In reply to SpanKY from comment #5)
> (In reply to Joshua Kinard from comment #4)
> 
> yes, it shouldn't be too hard to do that.  i'm asking if you really want
> this now or if you can wait until the 7.10 release which is slated for June.

So it's late July now...

[Comment 7 SpanKY 2015-07-22 07:22:23 UTC]

(In reply to Joshua Kinard from comment #6)

the branch was cut and they're fixing blockers now before the release

[Comment 8 SpanKY 2015-08-28 22:14:55 UTC]

7.10 is in the tree now

http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67440d809893201bd0011da9a9d060a2538cbd42