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).
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.
(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.
(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.
(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?
(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.
(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...
(In reply to Joshua Kinard from comment #6) the branch was cut and they're fixing blockers now before the release
7.10 is in the tree now http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67440d809893201bd0011da9a9d060a2538cbd42
