ia64-unknown-linux-gnu-gcc -pipe -mtune=mckinley -O2 -flto -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -o nsd-control answer.o axfr.o buffer.o configlexer.o configparser.o dname.o dns.o edns.o iterated_hash.o lookup3.o namedb.o nsec3.o options.o packet.o query.o rbtree.o radtree.o rdata.o region-allocator.o rrl.o tsig.o tsig-openssl.o udb.o udbradtree.o udbzone.o util.o nsd-control.o strlcat.o strlcpy.o b64_pton.o b64_ntop.o -lssl -lcrypto -levent configparser.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters lto1: fatal error: LTO_tags out of range: Range is 0 to 365, value is 5690 compilation terminated. lto-wrapper: /usr/ia64-unknown-linux-gnu/gcc-bin/4.8.2/ia64-unknown-linux-gnu-gcc returned 1 exit status /usr/lib/gcc/ia64-unknown-linux-gnu/4.8.2/../../../../ia64-unknown-linux-gnu/bin/ld: lto-wrapper failed Reproducible: Always
Created attachment 371560 [details] emerge --info
Created attachment 371562 [details] build.log
It is noteworthy to say that I never enabled LTO anywhere.
I also updated sys-devel/binutils to 2.24-r2 and rebuilt the whole system (-e @world). The problem discribed here did not appear again. (Instead glibc tests segfault.)
Regarding enabling lto: ... checking for bison... bison -y checking if ia64-unknown-linux-gnu-gcc supports -flto... yes checking for an ANSI C-conforming const... yes ... And later: >>> Compiling source in /var/tmp/portage/net-dns/nsd-4.0.0/work/nsd-4.0.0 ... make -j6 ia64-unknown-linux-gnu-gcc -I. -pipe -mtune=mckinley -O2 -flto -c answer.c ... Did your latest build (that succeeded) also use -flto ?
(In reply to Tom Hendrikx from comment #5) > checking if ia64-unknown-linux-gnu-gcc supports -flto... yes > ia64-unknown-linux-gnu-gcc -I. -pipe -mtune=mckinley -O2 -flto -c answer.c Hm, so NSD auto-enables LTO if the compiler supports it? > Did your latest build (that succeeded) also use -flto ? Probably. I changed nothing except updating binutils. Building NSD again shows that it still enables LTO.
nsd4 by default enables lto, yes. It can be disabled by passing --disable-flto during configure. But that does not seem necessary when binutils is new enough: I searched a bit around for gentoo+lto, and found some blogpost [1] that mainly described issues with binutils that were too old (version < 2.21). Could you check which binutils version was installed before you upgraded it? Since binutils 2.23.2 is stable everywhere, with latest stabilisation change more than 6 weeks ago, I don't it's necessary to update the ebuild with a minimal version for binutils, but I don't know what offical gentoo policy on that is... [1] http://realnc.blogspot.nl/2012/06/building-gentoo-linux-with-gcc-47-and.html
(In reply to Tom Hendrikx from comment #7) > Could you check which binutils version was installed before you upgraded it? attachment #371560 [details] says: sys-devel/binutils: 2.23.2
hrmz, found binutils version 2.23.2 in your emerge --info, sorry about that. I do see you're using gcc 4.8.2 which is not even ~arch masked yet, that might need the ~arch binutils. Not really sure and I can't test, since I don't have hardware available for your arch ;) Maybe we should consider this a fluke due to unstable buildchain?
(In reply to Tom Hendrikx from comment #9) > Maybe we should consider this a fluke due to unstable buildchain? Sure. If someone else runs into this, he can reopen the bug.
