Summary: | net-dns/nsd-4.0.0 - lto1: fatal error: LTO_tags out of range: Range is 0 to 365, value is 5690 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | [OLD] Core system | Assignee: | Tom Hendrikx <tom> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | proxy-maint, wschlich |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | IA64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
build.log |
Description
Dennis Schridde
2014-03-02 14:52:10 UTC
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. |