------- Comment #17 from steven at gcc dot gnu dot org 2010-04-29 11:39 ------- I've played a bit with modified .s files by hand, and as/ld work if the LTO sections follow the other sections.
The normal order of output with -flto looks like this in the .s file: LTO sections (the __GNU_LTO stuff) .text / .data / etc. (all non-LTO sections) LTO __section_names section With this order I get the linker error. I do *not* get the linker error if I re-order the .s file by hand to look like this: .text / .data / etc. (all non-LTO sections) LTO sections (the __GNU_LTO stuff) LTO __section_names section With this order, the .s file looks identical with and without -flto, except for the extra LTO sections after the non-LTO stuff of course. And with this order, the linker doesn't give an error. I don't understand this at all. It is almost as if the compiler somehow writes an address relative to start-of-file, but the compiler doesn't know about addresses (it can write labels and such, but not count bytes from start-of-file). Anyway, I did some research with Google and we are not the first to encounter this problem. Apparently it doesn't happen in 32-bits mode, so I'll implement that now and try that. The important conclusion for me, is that the LTO patch is OK and the bug is somewhere else :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
