[Bug gold/16417] executable linked with gold segfaults before main

https://sourceware.org/bugzilla/show_bug.cgi?id=16417 --- Comment #10 from Alan Modra --- I was also puzzled as to why libpthread.so is exporting symbols defined in libc.so, and vice versa, but on looking at the code there is some justification for some of the duplication. The libc versions have

[Bug gold/16808] ld.gold doesn't know about -Ofast

https://sourceware.org/bugzilla/show_bug.cgi?id=16808 --- Comment #5 from Que Quotion --- Marking my own bug invalid. This was a misunderstanding. Somehow I'd gotten away with feeding the linker flags like -Ofast before, but had I read the documentation I might have realized this doesn't make se

[Bug gold/16417] executable linked with gold segfaults before main

https://sourceware.org/bugzilla/show_bug.cgi?id=16417 --- Comment #9 from Cary Coutant --- "Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only

[Bug ld/16807] Bad behavior with resources of Windows applications with recent binutils upgrade on Cygwin64

https://sourceware.org/bugzilla/show_bug.cgi?id=16807 --- Comment #1 from Nick Clifton --- Hi Corinna, I have started looking into this bug, but I am a bit stumped. :-( I guess that the problem is connected with the default manifest being added in to the executable's resources. But look

[Bug gold/16808] ld.gold doesn't know about -Ofast

https://sourceware.org/bugzilla/show_bug.cgi?id=16808 --- Comment #4 from Cary Coutant --- > Is the same true for ld.gold? In which case -O, -Os, -Og, -Ofast are not > implemented and -O1 = -O2 = -O3 = -O4 and so on? At -O1 and above, gold will use a higher compression level with --compress-debu

[Bug gold/16804] gold rejects kernel linker script

https://sourceware.org/bugzilla/show_bug.cgi?id=16804 --- Comment #9 from cvs-commit at gcc dot gnu.org --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch,

[Bug gold/16808] ld.gold doesn't know about -Ofast

https://sourceware.org/bugzilla/show_bug.cgi?id=16808 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug gold/16808] ld.gold doesn't know about -Ofast

https://sourceware.org/bugzilla/show_bug.cgi?id=16808 --- Comment #2 from Que Quotion --- Changed this option in LDFLAGS from -Ofast to -O4 and compilation proceeds as normal. -- You are receiving this mail because: You are on the CC list for the bug. __

[Bug gold/16808] ld.gold doesn't know about -Ofast

https://sourceware.org/bugzilla/show_bug.cgi?id=16808 --- Comment #1 from quequotion at mailinator dot com --- The manpage for ld says: -O level If level is a numeric values greater than zero ld optimizes the output. This might take significantly longer and therefore probably should only be e

[Bug gold/16808] New: ld.gold doesn't know about -Ofast

https://sourceware.org/bugzilla/show_bug.cgi?id=16808 Bug ID: 16808 Summary: ld.gold doesn't know about -Ofast Product: binutils Version: 2.24 Status: NEW Severity: normal Priority: P2 Component: gold A

[Bug binutils/13227] GCC now produce slim LTO files. Those can't be linked/archived or nm w/o plugin used. It would be useful to output diagnostics when user attempts so

https://sourceware.org/bugzilla/show_bug.cgi?id=13227 --- Comment #3 from rguenther at suse dot de --- On Thu, 3 Apr 2014, hubicka at ucw dot cz wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=13227 > > --- Comment #2 from hubicka at ucw dot cz --- > > Bug 14698 Summary: ar, nm and ranl