I can't compile sys-devel/gcc-4.7.3-r1 and this is worrying (especially since I can't recompile 4.6.3 either due to an "internal compiler error") I have these "reloc errors" quite frequently (eg bug #487258) for some weeks. AMD64, MAKEOPTS="-j1", no ccache Reproducible: Always
Created attachment 360804 [details] emerge --info
Created attachment 360806 [details] build.log
simplify your CFLAGS. drop all the -f flags and try building again.
Got a similar issue today while compiling mesa. After several manual "make", <remove buggy .la, .a files>, "make," ... , ... then ebuild merge, I was able to get the installation done. For gcc, the complex bootstrap phases + environment changes make this workaround unsuitable. I still need to find out why gcc/coreutils create buggy files, and in the first place how "corrupted" are they. For now I'll follow your solution about CFLAGS and will let you know, but let me reiterate that this is a recent issue, since I used gcc 4.6.3 and these CFLAGS for months without trouble. Could this be related to a glibc upgrade ?
Created attachment 361446 [details] build.log failure using simple CFLAGS build failure excerpt without the -f* specific CFLAGS: x86_64-pc-linux-gnu-gcc -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -Wl,-O1 -Wl,--as-needed -o cc1plus cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o cc1plus-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -ldl -rdynamic -ldl -lz libbackend.a(insn-attrtab.o): In function `insn_default_latency_pentium': insn-attrtab.c:(.text+0xc351): relocation truncated to fit: R_X86_64_PC32 against symbol `get_attr_type' defined in .text section in libbackend.a(insn-attrtab.o) insn-attrtab.c:(.text+0xc360): relocation truncated to fit: R_X86_64_PC32 against symbol `which_alternative' defined in COMMON section in libbackend.a(recog.o) insn-attrtab.c:(.text+0xc371): relocation truncated to fit: R_X86_64_PC32 against symbol `get_attr_memory' defined in .text section in libbackend.a(insn-attrtab.o) insn-attrtab.c:(.text+0xc386): relocation truncated to fit: R_X86_64_PC32 against symbol `get_attr_pent_pair' defined in .text section in libbackend.a(insn-attrtab.o) insn-attrtab.c:(.text+0xc39b): relocation truncated to fit: R_X86_64_PC32 against symbol `get_attr_memory' defined in .text section in libbackend.a(insn-attrtab.o) insn-attrtab.c:(.text+0xc3b0): relocation truncated to fit: R_X86_64_PC32 against symbol `get_attr_pent_pair' defined in .text section in libbackend.a(insn-attrtab.o) insn-attrtab.c:(.text+0xc6b5): relocation truncated to fit: R_X86_64_PC32 against symbol `const1_operand' defined in .text section in libbackend.a(insn-preds.o) insn-attrtab.c:(.text+0xc6bf): relocation truncated to fit: R_X86_64_PC32 against symbol `which_alternative' defined in COMMON section in libbackend.a(recog.o) insn-attrtab.c:(.text+0xc6d0): relocation truncated to fit: R_X86_64_PC32 against symbol `get_attr_memory' defined in .text section in libbackend.a(insn-attrtab.o) insn-attrtab.c:(.text+0xc6e5): relocation truncated to fit: R_X86_64_PC32 against symbol `get_attr_pent_pair' defined in .text section in libbackend.a(insn-attrtab.o) insn-attrtab.c:(.text+0xc6fa): additional relocation overflows omitted from the output collect2: ld returned 1 exit status full build.log.gz attached
You'll have to rebuild your whole system without the graphite flags. GCC already strips them so rebuilding it won't make a difference.
I have a theory I'll test soon: # cat /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3 The 32bits path comes 1st, I can not tell where this file comes from. (its creation does not relate to the gcc installation)
Also found the following possibly confusing: # cat /etc/ld.so.conf.d/05binutils.conf # unknown origin /usr/x86_64-pc-linux-gnu/lib # equery b /usr/lib64/libiberty.a /usr/lib64/binutils/x86_64-pc-linux-gnu/2.23.1/libiberty.a sys-devel/binutils-2.23.1 (/usr/lib64/binutils/x86_64-pc-linux-gnu/2.23.1/libiberty.a) sys-devel/gdb-7.5.1 (/usr/lib64/libiberty.a) (both differ) This /etc/ld.so.conf.d/ directory seems like the Pandora's box.
Created attachment 363152 [details] badly generated so file changing the order of path in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf didn't do the trick as I ended up with this one today : /usr/x86_64-pc-linux-gnu/bin/ld: libbackend.a(graphite-sese-to-poly.o): bad reloc symbol index (0x728c >= 0xac) for offset 0x7982 in section `.text' In case anyone knows about this, here is attached graphite-sese-to-poly.o from the generated libbackend.a (usable with readelf -h -d -s -W ) In the build.log, the lines related to this lib are : x86_64-pc-linux-gnu-gcc -c -O -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/. -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../include -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libcpp/include -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libdecnumber/bid -I../libdecnumber -I/usr/include/cloog-ppl /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/graphite-poly.c -o graphite-poly.o [...] then x86_64-pc-linux-gnu-ar rc [...] then: /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./prev-gcc/g++ -B/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/libstdc++-v3/libsupc++ -L/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -c -O -m64 -O2 -march=native -pipe -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/. -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../include -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libcpp/include -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libdecnumber/bid -I../libdecnumber -I/usr/include/cloog-ppl /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/graphite-poly.c -o graphite-poly.o [...] then x86_64-pc-linux-gnu-ar rc [...] then: /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./prev-gcc/g++ -B/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/libstdc++-v3/libsupc++ -L/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -c -O -m64 -O2 -march=native -pipe -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/. -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../include -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libcpp/include -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/../libdecnumber/bid -I../libdecnumber -I/usr/include/cloog-ppl /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/gcc/graphite-poly.c -o graphite-poly.o [...] ^^ = exactly the same one except it hasn't the "-gtoggle" parameter [...] then x86_64-pc-linux-gnu-ar rc the only reference I could find about this is here: http://sourceware.org/bugzilla/show_bug.cgi?id=3469 (related to binutils) This forum's thread seems related: http://forums.gentoo.org/viewtopic-p-4163667.html (I also experience "random" segfaults at compile-time) Could someone compare the above lines with its own build.log please ? Remember that I've an -floop-enabled gcc 4.6.3 (which never caused me problem during 2013) which now fails to compile any gcc version.
# ll ./build/{prev-,}gcc/{libbackend.a,graphite-sese-to-poly.o} -rw-r--r-- 1 81120 12 nov. 10:53 ./build/gcc/graphite-sese-to-poly.o -rw-r--r-- 1 24101140 12 nov. 11:00 ./build/gcc/libbackend.a -rw-r--r-- 1 878480 12 nov. 10:10 ./build/prev-gcc/graphite-sese-to-poly.o -rw-r--r-- 1 168093084 12 nov. 10:25 ./build/prev-gcc/libbackend.a ./build/prev-gcc/libbackend.a seems ok: $ readelf -aW /build/gcc/graphite-sese-to-poly.o|grep 7982 0000000000007982 0000009300000002 R_X86_64_PC32 0000000000000000 _Z16ppl_set_coef_gmpP25ppl_Linear_Expression_tagmP12__mpz_struct - 4 this is ok, as are ./build/prev-gcc/graphite-sese-to-poly.o and the one inside ./build/prev-gcc/libbackend.a, ... but... not the one inside ./build/gcc/libbackend.a : $ readelf -aW graphite-sese-to-poly.o|grep 7982 0000000000007982 0000728c00000002 R_X86_64_PC32 bad symbol index: 0000728c
Very probably related: can't emerge dovecot either gcc segfault or : /bin/sh ../../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -std=gnu99 -O2 -march=native -pipe -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -export-dynamic -no-undefined -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -o libdovecot-compression.la -rpath /usr/lib64/dovecot libcompression.la ../lib/liblib.la -lz -lbz2 -lrt libtool: link: x86_64-pc-linux-gnu-gcc -shared -fPIC -DPIC -Wl,--whole-archive ./.libs/libcompression.a ../lib/.libs/liblib.a -Wl,--no-whole-archive -lz -lbz2 -lrt -O2 -march=native -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -Wl,-soname -Wl,libdovecot-compression.so.0 -o .libs/libdovecot-compression.so.0.0.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: ../lib/.libs/liblib.a(str-sanitize.o): bad reloc symbol index (0x40000014 >= 0x16) for offset 0x1b9 in section `.text' ../lib/.libs/liblib.a(str-sanitize.o): could not read symbols: Bad value
Following the advises of tomboy65 and grknight on IRC, I did: $ PORTAGE_BINHOST="http://packages.gentooexperimental.org/packages/amd64-stable/" emerge -avG binutils gcc glibc gmpc libtool mpc fine ! Then emerge @system But when it cames to compile gcc (36th of 44 packages), the issue reappeared : [...] x86_64-pc-linux-gnu-gcc -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -Wl,-O1 -Wl,--as-needed -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -ldl -lz /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: libbackend.a(tree-eh.o)(.text+0xce2f): reloc against `dump_file': error 2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status
Created attachment 364088 [details] log of calling ld several times successively The segfaults at link-time is the main symptom of this issue. This continues using the binary package of binutils 2.23.1. After several consecutive ebuild merge && [manually remove corrupted files] && ebuild merge && ... I was able to compile binutils 2.21.1-r1. The segfaults at link-time continues to arise ! dovecot is a good test-case where I can consistently reproduce the crash : libtool: link: x86_64-pc-linux-gnu-gcc -std=gnu99 -O2 -march=native -save-temps -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -o test-http-response-parser test-http-response-parser.o .libs/http-date.o .libs/http-parser.o .libs/http-header.o .libs/http-header-parser.o .libs/http-transfer-chunked.o .libs/http-message-parser.o .libs/http-response-parser.o -Wl,--export-dynamic ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -ldl -lrt collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped I found that sleep'ing 0.1 second between two successive makes the bug to appears, while sleep 0.2 second was ok ! See the attached log. Any help still welcomed.
Created attachment 364090 [details] log of calling ld several times successively (forgot to add the corresponding command-line for the test-case)
Removing -Wl,--export-dynamic from the command-line makes the segfault still present but very less likely to happen.
Created attachment 364092 [details] loop of collect2 invokations using the verbose mode I can track the segfault down this line: $ pushd /var/tmp/portage/net-mail/dovecot-2.2.6/work/dovecot-2.2.6/src/lib-http $ make # build the basics / or use ebuild compile $ /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/collect2 \ -dynamic-linker /lib64/ld-linux-x86-64.so.2 \ -o test-http-response-parser /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/crt1.o \ /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/crti.o \ /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/crtbegin.o \ \ -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3 \ -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64 \ -L/lib/../lib64 \ -L/usr/lib/../lib64 \ -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/lib \ -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../.. \ \ test-http-response-parser.o \ .libs/http-date.o \ .libs/http-parser.o \ .libs/http-header.o \ .libs/http-header-parser.o \ .libs/http-transfer-chunked.o \ .libs/http-message-parser.o \ .libs/http-response-parser.o \ ../lib-test/.libs/libtest.a \ ../lib/.libs/liblib.a \ -ldl \ -lrt \ -lgcc \ -lgcc_s \ -lc \ /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/crtend.o \ /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/crtn.o # throws either > collect2: erreur: ld terminé par le signal 11 [Erreur de segmentation], core dumped # either > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value > collect2: error: ld returned code 1 COMPILER_PATH, LIBRARY_PATH, COLLECT_GCC and COLLECT_LTO_WRAPPER (which are used during portage compilation) do not affect significantly the result. (see the attachment of this command ran in a loop) Considering that collect2 is part of gcc and that I can *not* compile gcc (with ou without splitdebug, in order to use collect2.debug) and given that I can't find a debug-enabled build of gcc I don't yet how I could dig this further. Is someone able to reproduce this behavior please ? I left with these hypothesis: - this is a subtle misconfig of my /etc (how could it be ?) - this is a subtle bug of gcc - this is a subtle bug of binutils (like bug #433669 or bug #362897, though there are about binutils) - this is an unlikely hardware bug (memory / filesystem corruption) - this is a rootkit
Given that I can often get spurious reboots consequently to these segfaults, here is a log (while looping over ld), thanks to netconsole: [ 494.200752] ld[4244]: segfault at 202628340 ip 00007faaa30c79da sp 00007fff446df4b0 error 4 in libbfd-2.21.1.so[7faaa3050000+e1000] [ 503.610720] ld[4482]: segfault at 2022e3768 ip 00007fb2815e89da sp 00007fffb4ca2470 error 4 in libbfd-2.21.1.so[7fb281571000+e1000] [ 505.154198] ld[4519]: segfault at 201e85dd8 ip 00007fde37deb9da sp 00007fffc48583e0 error 4 in libbfd-2.21.1.so[7fde37d74000+e1000] [ 525.870999] ld[5047]: segfault at 2019b1250 ip 00007f6d1a2369da sp 00007ffffb455a90 error 4 in libbfd-2.21.1.so[7f6d1a1bf000+e1000] [ 525.998140] ld[5049]: segfault at 200aabf48 ip 00007f49dc4ae9da sp 00007fff63396310 error 4 in libbfd-2.21.1.so[7f49dc437000+e1000] [ 527.932531] ld[5097]: segfault at 2021dadd8 ip 00007f40582039da sp 00007fffc29dfd40 error 4 in libbfd-2.21.1.so[7f405818c000+e1000] [ 528.044603] ld[5099]: segfault at 2023cf3b8 ip 00007f0db5f6a9da sp 00007fffa1bf5cd0 error 4 in libbfd-2.21.1.so[7f0db5ef3000+e1000] [ 528.159949] ld[5101]: segfault at 20153c898 ip 00007f14ec48a9da sp 00007fffefbb0870 error 4 in libbfd-2.21.1.so[7f14ec413000+e1000] [ 528.282107] ld[5103]: segfault at 2026d6340 ip 00007f8f2c6269da sp 00007fffa21a6ee0 error 4 in libbfd-2.21.1.so[7f8f2c5af000+e1000] [ 528.407364] ld[5107]: segfault at 201adc250 ip 00007f977e8a59da sp 00007fffaffffb40 error 4 in libbfd-2.21.1.so[7f977e82e000+e1000] [ 535.189557] ld[5279]: segfault at 200abf340 ip 00007f53d4a4f9da sp 00007fff8aa0d700 error 4 in libbfd-2.21.1.so[7f53d49d8000+e1000]
very similar: bug #401455
reported against upstream where a very similar issue (though affecting mips) has already been reported: https://sourceware.org/bugzilla/show_bug.cgi?id=16139 see the gdb log file there for more info.
gcc-4.9 is stable now, so throwing away older bugs we don't plan on doing backports for as this should be fixed w/4.9+. please re-open if it's still an issue with 4.9.3+ though.
